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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers