On Fri, Dec 23, 2011 at 1:58 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 23.12.2011 19:21, Robert Haas wrote:
>>
>> On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Software<holec@jphsw.cz>
>> =A0wrote:
>>>
>>> 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=3D"client_encoding=3DWIN1250" doesn't work.
>>
>> I think you need a "-c" in there somewhere, maybe something like this:
>>
>> options=3D'-cclient_encoding=3DWIN1250'
>>
>> ...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=3D'auto' to the params it passes to PQconnectdbParams. Th=
at
> overrides any setting you manually pass in the backend command-line optio=
ns.
>
> That doesn't seem desirable, actually. That could be changed easily, by
> passing the client_encoding=3D'auto' setting *before* dbname in the
> PQconnectdbParams call. The options given by the user are parsed from dbn=
ame
> setting, so if we passed them in different order, the manually given opti=
ons
> would override the client_encoding=3D'auto' setting, not the other way ro=
und.
> 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.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
