Re: client_encoding directive is ignored in

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

In response to

Responses

Browse pgsql-hackers by date

  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