>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.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) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
