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