Re: encoding of PostgreSQL messages

On Thu, Feb 12, 2009 at 10:28:38PM +0900, Hiroshi Inoue wrote:

> >>> Reflecting on the bigger picture ... I would imagine that the vast
> >>> majority of existing applications depend on client_encoding settings
> >>> that come from postgresql.conf, ALTER USER SET, ALTER DATABASE SET, or
> >>> just the default (== database encoding). I don't think a solution that
> >>> penalizes those cases and makes only

While I agree that it is desirable to find a solution which
does not break (or at least "allows to make not break") such
applications I tend to think that those applications are not
based on sound engineering with respect to this detail. A
clean solution - which allows for the unclean solution to
coexist - is very desirable.

One might introduce a GUC variable "pre_connect_encoding".
If not set it would default to 7-bit ascii as proposed but
can be set to either some explicit encoding or else to, say,
"deduce_from_environment" which would reinstate the current
behaviour. That would allow those who don't want to/cannot
fix client code to keep things working as before.

> not only but also the JDBC driver or the ODBC driver sends the
> startup packet including the client_encoding. Libpq can be changed
> to allow *client_encoding=xxxxx* definition in conninfo.
>
> > the case of setting it via
> >>> PGCLIENTENCODING work nicely is going to make very many people happy.
>
> Not a few libraries/applications issue SET client_encoding to ...
> immediately after the connection was establised. What's wrong with
> urging such clients to eliminate the SET commands and use the nice
> feature of FE/BE procotol?

Sounds sane to me as a developer using a Python PostgreSQL
adapter. It can be argued that it is *still* useful to have
a well known initial encoding (7-bit ascii) -- this would be
used for returning an error if the startup packet included
an invalid encoding ...

Also it would allow current application code to assume that
encoding until the encoding can be set by current means -
this would allow current application code to behave
correctly without having to wait for database adapter code
to support setting the encoding in the startup packet.

Or put another way: I could fix GNUmed properly NOW rather
than having to wait for psycopg2 to support setting the
client encoding in the startup packet.

Thanks,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346