Re: Collations versus user-defined functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Collations versus user-defined functions
Date
Msg-id 27925.1300036596@sss.pgh.pa.us
Whole thread Raw
In response to Re: Collations versus user-defined functions  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Collations versus user-defined functions
Re: Collations versus user-defined functions
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Mar 12, 2011 at 06:06:33PM -0500, Tom Lane wrote:
>> I remain unconvinced, because there are too many corner cases.  Should
>> collation propagate up out of a subselect?  How about a CTE?  You're
>> starting to get into some pretty weird action-at-a-distance situations
>> if so, analogous to the function-input-arguments case that you were just
>> saying should NOT propagate collation.  And I still don't see anything
>> in the text of the spec to justify it.

> I said don't propegate the collation *state*, the collation should be
> propegated.

Well, it's exactly that distinction that's bugging me.  It seems a bit
arbitrary if collation propagates in certain cases where collation state
doesn't.  I'm concerned in particular that we're going to find ourselves
backend into a corner if someone comes up with a different reading of
the spec.  The proposed implementation will be incapable of propagating
collation state across subselect boundaries (because the post-parse scan
is going to operate at most one subquery at a time), so if someone
convinces us that we should do that, what then?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Collations versus user-defined functions
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Collations versus user-defined functions