>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
Tom> I eventually decided that we were overthinking this problem. At Tom> least for regular ordered-set aggregates, we can just deem that Tom> the collation of the aggregate is indeterminate unless all the Tom> inputs (both direct and aggregated) agree on the collation to Tom> use. This gives us the right answer for all the standard Tom> aggregates, which have at most one collatable input, and it's Tom> very unclear that anything more complicated would be an Tom> improvement. I definitely didn't like the hack that was in Tom> there that'd force a sort column to absorb a possibly-unrelated Tom> collation. Yeah, I can go along with that, but see below. Tom> For hypotheticals, I agree after reading the spec text that Tom> we're supposed to unify the collations of matching hypothetical Tom> and aggregated arguments to determine the collation to use for Tom> sorting that column. Yeah, the spec seemed clear enough on that. Tom> I see that the patch just leaves these columns out of the Tom> determination of the aggregate's result collation. That's okay Tom> for the time being at least, since we have no hypotheticals with Tom> collatable output types, but I wonder if anyone wants to argue Tom> for some other rule (and if so, what)? Any alternative seems a bit ad-hoc to me. The examples I've thought of which would return collatable types are all ones that would be implemented as plain ordered set functions even if their logic was in some sense hypothetical. For example you could envisage a value_prec(x) within group (order by y) that returns the value of y which sorts immediately before x, but this would just be declared as value_prec(anyelement) within group (anyelement) rather than engaging the hypothetical argument stuff. (It's this sort of thing that suggested pushing down the collation into the sort column even for non-hypothetical ordered set functions.) -- 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
