On Fri, Dec 23, 2011 at 1:58 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 23.12.2011 19:21, Robert Haas wrote: >> >> On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Software<ho...@jphsw.cz> >> wrote: >>> >>> I Have PostgreSQL server 8.4.9 on Linux, database utf-8 and Client app on >>> Windows (VC++ and libpq.dll). >>> I need to use user account with non-ASCII and PQconnectdb() with >>> options="client_encoding=WIN1250" doesn't work. >> >> I think you need a "-c" in there somewhere, maybe something like this: >> >> options='-cclient_encoding=WIN1250' >> >> ...although, for some reason, I can't get that to work from psql, even >> though I can set other parameters using that syntax. > > > That's because of the changes in 9.1 to determine client_encoding > automatically from the system locale (commit 02e14562). Unless > PGCLIENTENCODING environment variable is set, psql adds > client_encoding='auto' to the params it passes to PQconnectdbParams. That > overrides any setting you manually pass in the backend command-line options. > > That doesn't seem desirable, actually. That could be changed easily, by > passing the client_encoding='auto' setting *before* dbname in the > PQconnectdbParams call. The options given by the user are parsed from dbname > setting, so if we passed them in different order, the manually given options > would override the client_encoding='auto' setting, not the other way round. > That seems like better behavior. Patch attached. It might be better to not > backpatch this, though, to avoid surprising and subtle changes in behavior > in application.
That seems like a sensible approach, but this patch doesn't seem to fix the problem for me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
