Jim Starkey wrote:
...The goal, I presume, is to eliminate all character set
conversion code from the server. If this is the case, shipping files
encoded with local character sets to the server for processing is a
serious problem, requiring character set tracking and conversion in
multiple locations.
> Jay Pipes wrote:
AFAIU, this is no different from the current MySQL, where one must
convert both on the client (SET NAMES utf8).
Ideally, if a file is encoded in latin-1 or some other non-UTF8
charset, then the client would encode into UTF8 and be done with it.
The idea to simplify to only UTF8 is to simplify *the server*, which
is what Drizzle focuses on. If a client (drizzle or otherwise) wishes
to pre-convert or post-convert to another character set (for instance,
because the underlying programming language does not handle UTF8
properly), then so be it, no?
Jim Starkey wrote:
The Nimbus protocols use only utf-8. The client API will probably
convert between utf-8 and the local character if I ever get around to
it. Properly speaking, the Nimbus API is JDBC, which has no truck for
non-unicode character sets. I may become more tolerant in my old age,
but I'm not quite there yet
I think something has been missed. Jim's model is to have no character
set handling in the server at all. If character set handling is
required in the system, it will be exclusively in the client. If
the server has to load data from arbitrary input files, it will need
character set conversions as well.
Cheers,
Ann
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
