Re: WITHIN GROUP patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WITHIN GROUP patch
Date
Msg-id 19446.1387671498@sss.pgh.pa.us
Whole thread Raw
In response to Re: WITHIN GROUP patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: WITHIN GROUP patch
List pgsql-hackers
[ still hacking away at this patch ]

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Not wanting to consider the sort args when there's more than one
>  Tom> doesn't square with forcing them to be considered when there's
>  Tom> 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".

I eventually decided that we were overthinking this problem.  At least
for regular ordered-set aggregates, we can just deem that the collation
of the aggregate is indeterminate unless all the inputs (both direct and
aggregated) agree on the collation to use.  This gives us the right
answer for all the standard aggregates, which have at most one collatable
input, and it's very unclear that anything more complicated would be an
improvement.  I definitely didn't like the hack that was in there that'd
force a sort column to absorb a possibly-unrelated collation.

For hypotheticals, I agree after reading the spec text that we're supposed
to unify the collations of matching hypothetical and aggregated arguments
to determine the collation to use for sorting that column.  I see that
the patch just leaves these columns out of the determination of the
aggregate's result collation.  That's okay for the time being at least,
since we have no hypotheticals with collatable output types, but I wonder
if anyone wants to argue for some other rule (and if so, what)?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: SQL objects UNITs
Next
From: Robert Haas
Date:
Subject: Re: SQL objects UNITs