Re: WITHIN GROUP patch
От | Andrew Gierth |
---|---|
Тема | Re: WITHIN GROUP patch |
Дата | |
Msg-id | 87ob4tefbl.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: WITHIN GROUP patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WITHIN GROUP patch
|
Список | pgsql-hackers |
>>>>> "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)
В списке pgsql-hackers по дате отправления: