[ thread renamed and cross-posted to pghackers, since this isn't only about JDBC anymore ] Barry Lind <[EMAIL PROTECTED]> writes: > The basic issue I have it that the server is providing an API to the > client to get the character encoding for the database and that API can > report incorrect information to the client. I don't have any objection to changing the system so that even a non-MULTIBYTE server can store and return encoding settings. (Presumably it should only accept encoding settings that correspond to single-byte encodings.) That can't happen before 7.2, however, as the necessary changes are a bit larger than I'd care to shoehorn into a 7.1.* release. > Thus I would be happy if getdatabaseencoding() returned 'UNKNOWN' or > something similar when in fact it doesn't know what the encoding is > (i.e. when not compiled with multibyte). I have a philosophical difference with this: basically, I think that since SQL_ASCII is the default value, you probably ought to assume that it's not too trustworthy. The software can *never* be said to KNOW what the data encoding is; at most it knows what it's been told, and in the case of a default it probably hasn't been told anything. I'd argue that SQL_ASCII should be interpreted in the way you are saying "UNKNOWN" ought to be: ie, it's an unspecified 8-bit encoding (and from there it's not much of a jump to deciding to treat it as LATIN1, if you're forced to do conversion to Unicode or whatever). Certainly, seeing SQL_ASCII from the server is not license to throw away data, which is what JDBC is doing now. > PS. Note that if multibyte is enabled, the functionality that is being > complained about here in the jdbc client is apparently ok for the server > to do. If you insert a value into a text column on a SQL_ASCII database > with multibyte enabled and that value contains 8bit characters, those > 8bit characters will be quietly replaced with a dummy character since > they are invalid for the SQL_ASCII 7bit character set. I have not tried it, but if the backend does that then I'd argue that that's a bug too. To my mind, a MULTIBYTE backend operating in SQL_ASCII encoding ought to behave the same as a non-MULTIBYTE backend: transparent pass-through of characters with the high bit set. But I'm not a multibyte guru. Comments anyone? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster