Re: Vague idea for allowing per-column locale

> (If this is an acceptable plan then we could tie this in with the proposed
> work of making the LIKE optimization work.  We wouldn't have to make up
> new ugly-named operators, we'd just have to do a bit of plain old type
> casting.)

If we are thinking about improvements at this level, why not go ahead
and reopen the discussion of how to do SQL9x national character sets,
collations, etc etc. istm that these will offer a solution for which the
current issues are a (hopefully large) subset.

We could use the type system to support this (my current preference);
others have suggested that this might be too heavy to be usable and had
alternate suggestions.

Issues with SQL9x include:

o character set/collation syntax for string literals

o internal representation

o appropriate operators and functions for these sets/collations

o I/O conventions between client and server (may use the current
scheme?)

o allowing these alternate character sets for table names (or wherever
allowed by SQL9x). How to expose, for example, equality operators to
allow internal PostgreSQL operation: is our current use of strcmp()
enough?

Comments?
                       - Thomas