Bruce Momjian schrieb:
Andreas wrote:

>I've got pg 8.1.4 from the binary Windows installer.
>Windows 2000 / German
>Now I entered "\d" into psql on the text-console and got this:
>>
>db_test=# \d
>ERRR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
>>
>What's up ?
>db_test was created UTF8 encoded
>
>
What does your client_encoding show? It should be UTF8 too.

it is.

db_test=# \d
ERRR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
db_test=# show client_encoding;
client_encoding

UTF8
(1 Zeile)

psql complains about the code page, too, now. (850 vs. 1252)
I'm sure I checked it the other day with a cmd that used 1252 and still
got the error for the \d command.

(end of broadcast)
TIP 5: don't forget to increase your free space map settings

Andreas <maps.on (AT) gmx (DOT) netwrites:
I've got pg 8.1.4 from the binary Windows installer.
Windows 2000 / German
Now I entered "\d" into psql on the text-console and got this:

db_test=# \d
ERRR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a

I can replicate this by using a UTF8 database and running the client
in a non-UTF8 locale. For example

$ LANG=de_DE.iso88591 psql postgres
Dies ist psql 8.2devel, das interaktive PostgreSQL-Terminal.

Geben Sie ein: \copyright Urheberrechtsinformationen
\h Hilfe SQL-Anweisungen
\? Hilfe interne Anweisungen
\g oder Semikolon, um eine Anfrage
\q um zu beenden

postgres=# \l
ERRR: invalid byte sequence for encoding "UTF8": 0xfc6d6572222c
TIP: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
postgres=# \d
ERRR: invalid byte sequence for encoding "UTF8": 0xfc6d6572220a
TIP: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
postgres=# \encoding
UTF8
postgres=#

The problem here is that psql is using gettext() to convert column
headings for its display to German, and gettext() sees its locale
as specifying IS, so that's the encoding it produces. When
that data is sent over to the server which thinks that the
client is using UTF8 encoding, because it hasn't been told any
different the server quite naturally barfs.

We've known about this and related issues with gettext for some time,
but a bulletproof solution isn't clear. For the moment all you can
do is be real careful about making your locale settings match up.

regards, tom lane

(end of broadcast)
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

I wrote:
We've known about this and related issues with gettext for some time,
but a bulletproof solution isn't clear. For the moment all you can
do is be real careful about making your locale settings match up.

I forgot to mention that it works fine if the server is told the client
encoding actually being used:

postgres=# \encoding iso8859-1
postgres=# \l
Liste der Datenbanken
Name | E | Kodierung
++
postgres | tgl | UTF8
regression | tgl | SQL_ASCII
template0 | tgl | UTF8
template1 | tgl | UTF8
(4 Zeilen)

postgres=# \d
Keine Relationen gefunden
postgres=#

A possible solution therefore is to have psql or libpq drive the
client_encoding off the client's locale environment instead of letting
it default to equal the server_encoding. But I'm not sure what
downsides that would have, and in any case it's not entirely clear that
we can always derive the correct Postgres encoding name from the
system's locale info.

regards, tom lane

(end of broadcast)
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Alvaro Herrera <alvherre (AT) commandprompt (DOT) comwrites:
Martijn van wrote:
>It seems to me that setting the client encoding based on the
>client-locale is the *only* sensible way of doing it.

Yes please.

FWIW I'm not sure if it really belongs in libpq, or it must be rather in
psql (and thus in every client).

libpq is what implements PGCLIENTENCDING, so I'd say that's where any
change in the default has to be handled. Presumably we'd still allow
PGCLIENTENCDING to override the locale?

regards, tom lane

(end of broadcast)
TIP 3: Have you checked our extensive FAQ?

Peter Eisentraut <peter_e (AT) gmx (DOT) netwrites:
Tom Lane wrote:
>A possible solution therefore is to have psql or libpq drive the
>client_encoding off the client's locale environment instead of
>letting it default to equal the server_encoding.

I have been proposing that for years, but just about now the Japanese
would speak up and protest I say, rush this in before anyone
notices.

I guess the key point might be "what do we do if the client locale
is C?" Perhaps if it's C, we continue to use the server encoding
as we have in the past. This would be a reasonable fallback in
other cases where we fail to deduce an encoding from the locale, too.

regards, tom lane

(end of broadcast)
TIP 3: Have you checked our extensive FAQ?