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

From Hannu Krosing
Subject Re: preventing encoding conversion while starting up
Date
Msg-id 1027026913.2155.11.camel@rh72.home.ee
Whole thread Raw
In response to Re: preventing encoding conversion while starting up  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2002-07-19 at 03:21, Tom Lane wrote:
> 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.

It may be possible to make it compatible with old clients by

1) starting with the same encodings as we always did

2) change the encoding only if both parties agree to do so. I think that
we could use listen/notify for that

So client must first ask for certain encoding by (mis)using listen and
will then be confirmed by notify

hannu=# listen "pg_encoding ISO-8859-15"; 
LISTEN
hannu=# notify "pg_encoding ISO-8859-15"; 
NOTIFY
Asynchronous NOTIFY 'pg_encoding ISO-8859-15' from backend with pid 2319
received.
hannu=# 

It would allow us to do it without protocol changes.

Not that i like it though ;(

> It seems like we've collected enough reasons for a protocol change that
> one might happen for 7.4.  I'd rather not have it happen in 7.3, though,
> because we don't have enough time left to address all the issues I'd
> like to see addressed...

But we could start making a list of issues/proposed solution, or we will
not have enough time in 7.4 cycle either.

--------------
Hannu




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: lock item completed
Next
From: nconway@klamath.dyndns.org (Neil Conway)
Date:
Subject: Re: RFC: listing lock status