On 28/05/10 19:27, Peter Eisentraut wrote:
I have been thinking about this collation support business a bit. Ignoring for the moment where we would get the actual collation routines from, I wonder how we are going to pass this information around in the system. Someone declares a collation on a column in a table, and somehow this information needs to arrive in bttextcmp() and friends.
Yes. Comparison operators need it, as do functions like isalpha().
Also, functions that take in a string and return one (e.g., substring), need to take in this information and return it back out. How should this work?
Hmm, I don't see what substring would need collation for. And it certainly shouldn't be returning it. Collation is a property of the comparison operators (and isalpha etc.), and the planner needs to deduce the right collation for each such operation in the query. That involves looking at the tables and columns involved, as well as per-user information and any explicit COLLATE clauses in the query, but all that happens at plan-time.
Option 1, make it part of the datum. That way it will pass through the system just fine, but it would waste a lot of storage and break just about everything that operates on string types now, as well as pg_upgrade. So that's probably out.
It's also fundamentally wrong, collation is not a property of a datum but of the operation.
Option 2, invent some new mechanism that accompanies a datum or a type whereever it goes. Kind of like typmod, but not really. Then the collation information would presumably be made available to functions through the fmgr interface. The binary representation of data values stays the same.
Something like that. I'm thinking that bttextcmp() and friends will simply take an extra argument indicating the collation, and we'll teach the operator / operator class infrastructure about that too.
One way to approach this is to realize that it's already possible to use multiple collations in a database. You just have to define separate < = > operators and operator classes for every collation, and change all your queries to use the right operator depending on the desired collation everywhere where you use < = > (including ORDER BYs, with the USING <operator> syntax). The behavior is exactly what we want, it's just completely inpractical, so we need something to do the same in a less cumbersome way.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
