Skip site navigation (1) Skip section navigation (2)

Detecting SQL_ASCII databases

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: (view raw, whole thread or download thread mbox)
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?




pgsql-jdbc by date

Next:From: Dave CramerDate: 2004-09-18 23:26:35
Subject: Re: Issues regarding code license of ported code.
Previous:From: Oliver JowettDate: 2004-09-18 22:21:16
Subject: Re: "Idle in Transaction" revisited.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group