From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
Cc: | pgman(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: client_encoding directive is ignored in |
Date: | 2003-02-16 17:45:08 |
Message-ID: | 28034.1045417508@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-16 17:54:23 | Re: location of the configuration files |
Previous Message | Patrick Welche | 2003-02-16 17:29:34 | Re: psql and readline |