<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-09-18 7:48 GMT+02:00 Sandro Santilli <span dir="ltr"><<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Sep 17, 2016 at 05:47:39PM -0700, Paul Norman wrote:<br>
> On 9/17/2016 8:09 AM, Sandro Santilli wrote:<br>
<br>
</span><span class="">> >Using a row-by-row approach, makes it impossible to build such<br>
> >dictionary, which is why my early attemps were just at producing<br>
> >the geometric part, very much like the GML output works, delegating<br>
> >composition of the whole final product to the caller (which could<br>
> >eventually also be a ROW-taking wrapper).<br>
><br>
> You're right. Joining different layers is fine, but each layer has<br>
> some common information that is needed.<br>
><br>
> Should it be an aggregate function then?<br>
<br>
</span>Probably, which means you'd also need to define a type<br>
to represent the state (including the dictionary, for example).<br>
It's enough stuff that might be better to move into its own<br>
extension.<br></blockquote><div><br></div><div>What do you think about the alternative of simply supplying the function with a name of a table or view assuming the the proposed structure then dynamically query it internally using the supplied bounds?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--strk;<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div></div>