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)