> 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 postmaster
starts up
case 2: -c 'client_encoding=some_encoding is set when postmaster
starts 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 variable but
actual client encoding is same as the database encoding. Thus
pg_client_encoding() returns the database encoding. 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 starts
up
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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
