user names & non-ASCII
Hi All, please help.
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.
SET CLIENT_ENCODING TO 'WIN1250' after PQconnectdb is too late because connection fails.
Best regards,
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 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.
--
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
Attachments:
let-client_encoding-be-manually-overrideable-in-psql-1.patchtext/x-diff; name=let-client_encoding-be-manually-overrideable-in-psql-1.patchDownload+12-12
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>
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