Re: preventing encoding conversion while starting up - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: preventing encoding conversion while starting up
Date
Msg-id 20020719.091053.26963343.t-ishii@sra.co.jp
Whole thread Raw
In response to Re: preventing encoding conversion while starting up  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: preventing encoding conversion while starting up  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Hannu Krosing <hannu@tm.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


pgsql-hackers by date:

Previous
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: RFC: listing lock status
Next
From: Tatsuo Ishii
Date:
Subject: Re: compiler warnings from cvs tip