Re: preventing encoding conversion while starting up

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

In response to

Responses

Browse pgsql-hackers by date

  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