Re: Collations versus user-defined functions

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

On sön, 2011-03-13 at 13:16 -0400, Tom Lane wrote:
> 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?

Do you have an example of what you have in mind?

There are some cases in the SQL standard that the current implementation
doesn't cover yet. But then again, we have also moved the type system
around a few times over the years as we have gained experience and found
the time to write the code.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2011-03-15 20:01:21 Re: FuncExpr.collid/OpExpr.collid unworkably serving double duty
Previous Message Peter Eisentraut 2011-03-15 18:44:30 Re: why is max standby delay only 35 minutes?