Josh Berkus <j...@agliodbs.com> writes:
> Can someone paste examples of the two syntax alternatives we're talking
> about here? I've lost track.
I'll leave it to Andrew to describe/defend exactly what his patch is
doing. The alternative I'm thinking about is that in CREATE AGGREGATE
as well as \da output, the argument list of an ordered-set aggregate
would look like
type1, type2, ... ORDER BY type3, type4, ...
if the aggregate only permits a fixed number of ordering columns
(as mode() does for example). If it permits a variable number of
ordering columns, you could have
type1, type2, ... ORDER BY [ type3, type4, ... ] VARIADIC something
99% of the time the right-hand part would just be "VARIADIC ANY"
but if an aggregate had need to lock down the ordering column types,
or the leading ordering column types, it could do that. If it needs
a variable number of direct arguments as well (which in particular
hypothetical set functions do) then you would write
[ type1, type2, ... ] VARIADIC something ORDER BY VARIADIC something
where we constrain the two "somethings" to be the same. (Again, these
would *usually* be ANY, but I can envision that an aggregate might want to
constrain the argument types more than that.) We have to constrain this
case because the underlying pg_proc representation and parser function
lookup code only allow the last argument to be declared VARIADIC. So
under the hood, this last case would be represented in pg_proc with
proargs looking like just "[ type1, type2, ... ] VARIADIC something",
whereas in the first two cases the proargs representation would contain
all the same entries as above.
We could substitute something else for ORDER BY without doing a lot
of violence to this, if people are really down on that aspect.
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
