Re: client_encoding directive is ignored in

> 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)?

The database encoding is set to the encoding when the database was
created and the default value of the client encoding is set to same as
the database encoding. This behavior will not be changed by the change
I proposed.

Anyway I will list up none default behaviors.

case 1: PGCLIENTENCODING environment variable is set when postmasterstarts up

case 2: -c 'client_encoding=some_encoding is set when postmasterstarts up

case 3: PGOPTIONS environment variable is set frontend starts up

case 4: GUC variable client_encoding is set
    current behavior: show client_encoding shows the encoding set by    PGCLIENTENCODING/postmaster opton/PGOPTIONS/GUC
variablebut    actual client encoding is same as the database encoding. Thus    pg_client_encoding() returns the
databaseencoding. Also    client/database encoding conversion is not peformed(bug).
 
    After changes: show client_encoding shows the encoding set by    PGCLIENTENCODING/postmaster opton/PGOPTIONS/GUC
variable.pg_client_encoding() returns the client encoding as    expected. Client/database encoding conversion will be
peformed.

case 5: PGCLIENTENCODING environment variable is set frontend startsup
case 6: SET client_encoding command is issued
    current behavior: show client_encoding shows the encoding set by    PGCLIENTENCODING/SET command.
pg_client_encoding()returns the    client encoding as expected. Client/database encoding conversion    will be
peformed.
    After changes: same as above.
--
Tatsuo Ishii