>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> Not wanting to consider the sort args when there's more than oneTom> doesn't square with forcing them to be
consideredwhen there'sTom> 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 caseTom> I'm worried about, because none of the ones
thatcan takeTom> 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)