Thread: user names & non-ASCII
Hi All, please help. =20 I Have PostgreSQL server 8.4.9 on Linux, database utf-8 and Client app on W= indows (VC++ and libpq.dll). I need to use user account with non-ASCII and PQconnectdb() with options=3D= "client_encoding=3DWIN1250" doesn't work. SET CLIENT_ENCODING TO 'WIN1250' after PQconnectdb is too late because conn= ection fails. =20 Best regards, =20 Pavel Holec
On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Software <holec@jphsw.cz> wrote: > I Have PostgreSQL server 8.4.9 on Linux, database utf-8 and=A0Client app = on > Windows (VC++ and libpq.dll). > I need to use user account with non-ASCII and PQconnectdb()=A0with > 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. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 23.12.2011 19:21, Robert Haas wrote: > On Thu, Dec 15, 2011 at 3:40 PM, Holec, JPH Software<holec@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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Attachment
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