>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
Tom> I eventually decided that we were overthinking this problem. AtTom> least for regular ordered-set aggregates, we
canjust deem thatTom> the collation of the aggregate is indeterminate unless all theTom> inputs (both direct and
aggregated)agree on the collation toTom> use. This gives us the right answer for all the standardTom> aggregates,
whichhave at most one collatable input, and it'sTom> very unclear that anything more complicated would be anTom>
improvement. I definitely didn't like the hack that was inTom> there that'd force a sort column to absorb a
possibly-unrelatedTom>collation.
Yeah, I can go along with that, but see below.
Tom> For hypotheticals, I agree after reading the spec text thatTom> we're supposed to unify the collations of matching
hypotheticalTom>and aggregated arguments to determine the collation to use forTom> sorting that column.
Yeah, the spec seemed clear enough on that.
Tom> I see that the patch just leaves these columns out of theTom> determination of the aggregate's result collation.
That'sokayTom> for the time being at least, since we have no hypotheticals withTom> collatable output types, but I
wonderif anyone wants to argueTom> 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)
