> o Don't accept character sequences those are not valid as their
> charset (signaling ERROR seems appropriate IMHO)
> o Make PostgreSQL more multibyte aware (for example, TRIM function and
> NAME data type)
> o Regard n of CHAR(n)/VARCHAR(n) as the number of letters, rather than
> the number of bytes
All good, and important features when we are done.
One issue: I can see (or imagine ;) how we can use the Postgres type
system to manage multiple character sets. But allowing arbitrary
character sets in, say, table names forces us to cope with allowing a
mix of character sets in a single column of a system table. afaik this
general capability is not mandated by SQL9x (the SQL_TEXT character set
is used for all system resources??). Would it be acceptable to have a
"default database character set" which is allowed to creep into the
pg_xxx tables? Even that seems to be a difficult thing to accomplish at
the moment (we'd need to get some of the text manipulation functions
from the catalogs, not from hardcoded references as we do now).
We should itemize all of these issues so we can keep track of what is
necessary, possible, and/or "easy".
- Thomas
