Thomas Lockhart writes:
> Another 7.1 project is to work on alternate languages and character
> sets, to decouple multibyte and locale from the default SQL_TEXT
> character set. This will probably bring up issues similar to the
> numeric problems, and since these character sets will be added as
> user-defined types it will be important for the backend to understand
> how to convert them for comparison operations, for example.
Really? I always thought the character set would be some separate entity
and perhaps an oid reference would be stored with every character string
and attribute. That would get you around any type conversion as long as
the functions acting on character types take this "header" field into
account.
If you want to go the data type way then you'd need to have some sort of
most general character set to cast to. That could be Unicode but that
would require that every user-defined character set be a subset of
Unicode, which is perhaps not a good assumption to make. Also, I wonder
how collations would fit in there. Collations definitely can't be ordered
at all, so casting can't be done in a controlled fashion.
Just wondering...
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
