Andrew Gierth <and...@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Tom> The key reason for that was, and remains, not having the
> Tom> behavior hard-wired in nodeAgg; I believe that this design
> Tom> permits things to be accomplished in aggregate implementation
> Tom> functions that would not have been possible with the original
> Tom> patch. I'm willing to accept some code growth to have that
> Tom> flexibility.
> Do you have an actual use case?
Not a concrete example of an aggregate to build, no; but it seemed
plausible to me that a new aggregate might want more control over
the sorting operation than was possible with your patch. Basically
the only flexibility that was there was to sort a hypothetical row before
or after its peers, right? Now it's got essentially full control over
the sort parameters.
One idea that comes to mind is that an aggregate that's interested in the
"top N" rows might wish to flip the sort order, so that the rows it wants
come out of the tuplesort first rather than last --- and/or it might want
to tell the tuplesort about the row limitation, so that the bounded-sort
logic can be used.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
