[postgis-devel] ST_Union specification questions

[Paragon Corporation]

Bryce,
 
We'll make sure to note it with a warning notice.  There are also
workarounds for lower versions of postgreSQL which aren't too bad.  
Like example we show here:
http://www.postgis.org/documentation/manual-svn/ST_MakeLine.html
 
We can document that too.  As it stands 8.4 is the only PostgreSQL in
PostGIS 2.0 we are supporting where an ordered aggregate would be an issue.
I don't think we should enforce too much constraint until possibly 2.1 if we
see alot of people are shooting themselves in the foot.
 
I think for PostGIS 2.0 we want to get out something useful and relatively
easy to use which won't be perfect (time is running out since December is
just around the corner and feature freeze time) 
I think we've got a lot of stuff already that people can use and are already
using and that's fantastic. We can use 2.0 release to learn from people how
they are using it to see what needs to be changed / reworked what they find
awkward to write etc.
 
Thanks,
Regina
 
 
 



  _____  

From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Bryce L
Nordgren
Sent: Monday, November 21, 2011 6:47 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] ST_Union specification questions


On Mon, Nov 21, 2011 at 10:56 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:



I would suggest you write a prototype of your own view of what should be
ST_MapAlgebra using your raster iterator. That would be more useful. More
constructive.



A] I was asking about ST_Union.
B] I wasn't talking about the raster iterator at all.
C] More useful and constructive than what? Pointing out something that I see
might cause problems which are potentially very difficult to debug? 

Regina's response was constructive, for which I am eternally grateful. In
this case, I learned that postgresql 9+ has a notion of ordered aggregates.
This modifies the question into: Is there any way to require that
expressions which depend on order occur only within an ordered aggregate?
Conversely, how do we disable (and should we attempt to disable) these
expressions on platforms (postgres < 9) which do not support ordered
aggregates, or in contexts where the aggregate ordering is not specified? 

At the very least, I think I'd suggest that the documentation for ST_Union
contain a fairly heavyhanded warning about the dangers of using  expressions
where the order matters in a non-ordered-aggregate context....

Bryce 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20111121/c20af7d7/attachment.html>