Re: Collations versus user-defined functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Collations versus user-defined functions
Date: 2011-03-13 17:16:36
Message-ID: 27925.1300036596@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martijn van Oosterhout <kleptog(at)svana(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitriy Igrishin 2011-03-13 18:44:15 Multi-language glossary of PostgreSQL terms.
Previous Message Robert Haas 2011-03-13 16:26:16 Re: Collations versus user-defined functions