Re: WITHIN GROUP patch

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)