Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Why? No matter how the backend's behavior regarding client_encoding
> changes, libpq won't be affected by it since 7.2 and 7.3 libpq does
> not use client_encoding anyway.
Doesn't client_encoding determine what encoding the backend sends to
the client?
It's probable that libpq itself is not affected by the selected
client_encoding, since it only passes data through. But I think that
applications are quite likely to be broken if we alter the backend's
behavior in a way that changes the default client encoding. That
strikes me as a change that should be made at a major release, not
a minor one --- people don't expect to get hit by compatibility
problems when they do a minor upgrade.
But this argument is mostly irrelevant if the proposed change will not
affect behavior in a default installation. I guess I'm not entirely
clear on exactly which cases it will affect. What will your proposed
change do in each possible combination (database encoding is SQL_ASCII
or not, client_encoding is defined in postgresql.conf or not,
PGCLIENTENCODING is set in postmaster's environment or not, etc)?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
