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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
