Barry Lind <barry@xythos.com> writes:
> Now it is an easy change in the jdbc code to use LATIN1 when the server
> reports SQL_ASCII, but I really dislike hardcoding support that only
> works in english speaking countries and Western Europe.
What's wrong with that? It won't be any more broken for people who are
not really using LATIN1, and it will be considerably less broken for
those who are. Seems like a net win to me, even without making the
obvious point about where the majority of Postgres users are.
It probably would be a good idea to allow the backend to store an
indication of character set even when not compiled for MULTIBYTE,
but that's not the issue here. To me, the issue is whether JDBC
makes a reasonable effort not to munge data when presented with
a backend that claims to be using SQL_ASCII (which, let me remind
you, is the default setting). Converting high-bit-set characters
to '?' is almost certainly NOT what the user wants you to do.
Converting on the assumption of LATIN1 will make a lot of people
happy, and the people who aren't happy with it will certainly not
be happy with '?' conversion either.
> All this does
> is move the problem from being one that non-english countries have to
> being one where it is a non-english and non-western european problem
> (eg. Eastern Europe, Russia, etc.).
Nonsense. The non-Western-European folks see broken behavior now
anyway, unless they compile with MULTIBYTE and set an appropriate
encoding. How would this make their lives worse, or even different?
I'm merely suggesting that the default behavior could be made useful
to a larger set of people than it now is, without making things any
worse for those that it's not useful to.
regards, tom lane
