Re: WITHIN GROUP patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WITHIN GROUP patch
Date
Msg-id 5603.1387729799@sss.pgh.pa.us
Whole thread Raw
In response to Re: WITHIN GROUP patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WITHIN GROUP patch
List pgsql-hackers
I wrote:
> ... So my reaction to this example is not
> that we should hack the behavior for plain ordered-set aggregates,
> but that we ought to find a rule that allows result-collation
> determination for hypotheticals.  We speculated upthread about
> "merge the collations normally, but ignore inputs declared ANY"
> and "merge the collations normally, but ignore variadic inputs".
> Either of those would get the job done in this example.  I kinda
> think we should pick one of these rules and move on.

Or, really, why don't we just do the same thing I'm advocating for
the plain-ordered-set case?  That is, if there's a single collation
applying to all the collatable inputs, that's the collation to use
for the aggregate; otherwise it has no determinate collation, and
it'll throw an error at runtime if it needs one.  We realized long
ago that we can't throw most need-a-collation errors at parse time,
because the parser lacks information about which functions need to
know a collation to use.  This seems to be in the same category.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WITHIN GROUP patch
Next
From: Alexander Korotkov
Date:
Subject: Re: PoC: Partial sort