From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | hannu(at)tm(dot)ee, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: preventing encoding conversion while starting up |
Date: | 2002-07-19 00:10:53 |
Message-ID: | 20020719.091053.26963343.t-ishii@sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Hannu Krosing <hannu(at)tm(dot)ee> writes:
> > On Thu, 2002-07-18 at 18:57, Tom Lane wrote:
> >> The problem is not just there. The real problem is that with this patch
> >> installed, it is impossible to report startup errors of any kind,
> >> because the client communication mechanism now depends on having working
> >> database access. I regard this as a fatal problem :-(
>
> > So the right way would be to always start up in us-ascii (7-bit) and
> > re-negotiate encodings later ?
>
> That might be one way out ... but doesn't it mean breaking the wire
> protocol? Existing clients aren't likely to know to do that.
No. We have been doing the encoding negotiation outside the existing
protocol. Aafter backend goes into the normal idle loop, clients sends
"set client_encoding" query if it wishes.
BTW, for the problem I reported, what about checking
IsTransactionState returns true before accessing database to find out
conversions?
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-07-19 00:14:05 | Re: compiler warnings from cvs tip |
Previous Message | Neil Conway | 2002-07-18 23:37:04 | Re: RFC: listing lock status |