> 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