Re: WITHIN GROUP patch

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> Not wanting to consider the sort args when there's more than one
Tom> doesn't square with forcing them to be considered when there's
Tom> just one. It's the same aggregate after all,

This logic is only applied in the patch to aggregates that _aren't_
hypothetical.

(thinking out loud:) It might be more consistent to also add the
condition that the single sort column not be a variadic arg. And/or
the condition that it be the same type as the result. Or have a flag
in pg_aggregate to say "this agg returns one of its sorted input
values, so preserve the collation".

>> Consider a construct like:

>> select max(common_val)
>> from (select mode() within group (order by textcol) as common_val
>> from ... group by othercol) s;

Tom> AFAICT none of the SQL-spec aggregates expose the kind of case
Tom> I'm worried about, because none of the ones that can take
Tom> multiple sort columns have a potentially collatable return type.

None of the spec's ordered-set functions expose any collation issue at
all, because they _all_ have non-collatable return types, period.

The problem only arises from the desire to make functions like
percentile_disc and mode applicable to collatable types.

--
Andrew (irc:RhodiumToad)