From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Detecting SQL_ASCII databases |
Date: | 2004-09-18 22:35:54 |
Message-ID: | 414CB84A.2050107@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
8.0 backends report the server_encoding value of the database via
ParameterStatus during startup. I'd like to use this to detect SQL_ASCII
databases and complain loudly.
The simplest approach is: if the server reports server_encoding on V3
startup, and it is SQL_ASCII, close the connecton and throw SQLException.
Perhaps a nicer approach is to do this on V3 connections:
1) if charSet=foo is specified, send a startup packet with
client_encoding = foo, otherwise send client_encoding = UNICODE. Set the
actual connection encoding to match client_encoding.
2) if the server reports server_encoding = SQL_ASCII and charSet was not
specified, close the connection and throw SQLException.
and change the >=7.3 logic in the V2 path to respect charSet if used,
for consistency with the 7.2 and V3 paths.
This lets users who have SQL_ASCII databases continue to use them by
explicitly specifying an encoding to use.
We still have some inconsistency in when you get the "this db is
SQL_ASCII, go away" class of error but I'm not sure if this is worth
fixing. It seems like we'd need an extra roundtrip on connection setup
to check it for 7.4 servers.
Another issue is whether we should allow charSet to be used when
server_encoding != SQL_ASCII. It seems confusing to allow this, but we
can only detect it after we've established a connection and set
everything up. Should we throw an error, change client_encoding back to
UNICODE, or just continue with the specified charSet?
Opinions?
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2004-09-18 23:26:35 | Re: Issues regarding code license of ported code. |
Previous Message | Oliver Jowett | 2004-09-18 22:21:16 | Re: "Idle in Transaction" revisited. |