From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
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 12:09:36 |
Message-ID: | 20030216.210936.104029191.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Actually the problem can be divided into two parts:
> > 1) backend does not process GUC client_encoding.
> > 2) libpq does not ask the backend's client_encoding, instead it asks
> > datanbase encoding when it starts up the connection. This is just a
> > mistake.
>
> > I think we could fix 1) without any backward compatibilty problem and
> > should be applied to both 7.3-STATBLE and current.
>
> If we change the backend behavior without changing libpq, aren't we
> breaking things even worse? As long as libpq behaves as in (2), hadn't
> the backend better init its idea of client_encoding to match
> database_encoding?
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.
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-02-16 14:10:05 | Re: location of the configuration files |
Previous Message | Gavin Sherry | 2003-02-16 08:50:12 | Re: [HACKERS] Linux.conf.au 2003 Report |