Noah Misch said: > Other aggregates based on this syntax might not desire such type unification.
Then there would have to be some way to distinguish that. Maybe those could have -1 and the standard hypothetical set functions -2, with some flag in CREATE AGGREGATE to sort it out. > Having parse analysis do that distorts the character of an "any" argument. I > think the proper place for such processing is the first call to a transition > function. Except there isn't one. > But let's not make the > parser presume that an aggordnargs=-1 aggregate always wants its "any" > arguments handled in the manner of the standard hypothetical set functions. This has to happen in the parser because these are errors that should be caught before execution: rank(foo) within group (order by bar,baz) rank(integercol) within group (order by textcol) And collations have to be resolved (pairwise) before sorting can happen: rank(textval COLLATE "C") within group (order by foo) -- sorts in "C" rank(textval COLLATE "C") within group (order by bar COLLATE "en_US") -- error (basically, in rank(x) within group (order by y) where x and y are collatable, the collation rules apply exactly as though you were doing (x < y), with all the implicit vs. explicit stuff included) And this: rank(1.1) within group (order by intcol) should become rank(1.1) within group (order by intcol::numeric) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
