> Adding aggregates is really less a
priority than adding support for
ARRAY[geom1,geom2,geom3...] for the relevant functions.
Are you sure that the planner
and indexes will manage arrays better?
reason I was thinking an array of aggregates is not as useful as an
ST_Intersection aggregate is that as you intersect geometries you are using less
memory rather than more
array you'd have to accumulate them first.
really is a sequential thing.
is not to say the ARRAY version isn't useful, but if you have a bunch of
geometries and then have to array them to get an intersection, then it would be
I could be wrong on that of course. Paul and
Nicklas can correct me on that since they are more familiar with the
on occasion come into the situation where the things I want to get intersection
of are in separate rows rather than separate layers and it is a tad bit annoying
to work around it. Doesn't come up often though.
Now with 9.4 coming with the FILTER syntax now
makes the across rows much easier if I actually had an ST_Intersection aggregate
that could take advantage of it.
> Yes, I guess you are right that it
would be possible to write a function that does the job from a collection
> But the function will have to do the
same thing. To calculate a result from 2 polygons, then use the resulting
polygon for calculation against the third polygon and so on. Just like an
aggregate function works.
introduces another question though?
an ST_Intersection aggregate double as an
just keep them separate.
would say keep them separate so that we have a parallel with ST_UnaryUnion and
also you can use it NOT as an aggregate to satisfy the array like