Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> Meh. I don't think you can have that and also have the behavior
> Tom> that multiple ORDER BY items aren't constrained to have the same
> Tom> collation; at least not without some rule that amounts to a
> Tom> special case for percentile_disc, which I'd resist.
> What the submitted patch does (as discussed in the comment in
> parse_collate) is to treat the sort argument as contributing to the
> collation only if there is exactly one sort arg.
Blech :-(
Not wanting to consider the sort args when there's more than one doesn't
square with forcing them to be considered when there's just one.
It's the same aggregate after all, and in general the semantics ought
to be the same whether you give one sort col or three.
We might be able to make this work sanely by considering only argument
positions that were declared something other than ANY (anyelement being
other than that, so this isn't leaving polymorphics in the cold entirely).
This is a bit unlike the normal rules for collation assignment but
it doesn't result in weird semantics changes depending on how many sort
columns you supply.
> Consider a construct like:
> select max(common_val)
> from (select mode() within group (order by textcol) as common_val
> from ... group by othercol) s;
AFAICT none of the SQL-spec aggregates expose the kind of case I'm worried
about, because none of the ones that can take multiple sort columns have a
potentially collatable return type. I don't think that justifies not
thinking ahead, though.
regards, tom lane