Обсуждение: JDBC Default Encoding

Hi,
 In PGStream, i see the default encoding "US-ASCII" which is overridden once we are connected to the database. But, if an error comes while connecting to the database for example user name is not correct, US-ASCII is used to decode the Server Message which prints ??? instead of actual error message when the locale is other than english (in my case it was zh_TW.utf8). If i change the default encoding of PGStream to UTF8, it works fine. Is there any specific reason for the default encoding to be the US-ASCII?

--Altaf Malik

---

Ahhh...imagining that irresistible "new car" smell?
Check out new cars at Yahoo! Autos.

On Tue, 1 May 2007, Altaf Malik wrote:

> In PGStream, i see the default encoding "US-ASCII" which is overridden
> once we are connected to the database. But, if an error comes while
> connecting to the database for example user name is not correct,
> US-ASCII is used to decode the Server Message which prints ??? instead
> of actual error message when the locale is other than english (in my
> case it was zh_TW.utf8). If i change the default encoding of PGStream to
> UTF8, it works fine. Is there any specific reason for the default
> encoding to be the US-ASCII?
>

Prior to connecting to the database we cannot assume what encoding the
conversation should occur in, so we use the lowest common denominator of
US-ASCII.  I guess the question is, with a database encoding of something
other than UTF-8, does the error message come back in the database
encoding or in UTF-8 like we asked.  I'm not sure when the server applies
our setting of client_encoding.  If it does come back in UTF-8 that would
be a good reason to switch to UTF-8 in the driver earlier, but if it comes
back in the database encoding there's not much we can do about that.

Kris Jurka

Kris Jurka <books@ejurka.com> writes:
> I'm not sure when the server applies
> our setting of client_encoding.

Immediately after switch scanning in PostgresMain, assuming you're
sending it the way I think.  This is before the backend subprocess
attempts to verify the database or user name ... however, this is
after authentication (pg_hba.conf processing) so there's quite a
variety of failure messages that would be sent in the postmaster's
default encoding, whatever that might be.  I'm afraid there's not
any really clean answer there.

            regards, tom lane