Re: preventing encoding conversion while starting up

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: preventing encoding conversion while starting up
Дата
Msg-id 1027026913.2155.11.camel@rh72.home.ee
обсуждение исходный текст
Ответ на Re: preventing encoding conversion while starting up  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: lock item completed
Следующее
От: nconway@klamath.dyndns.org (Neil Conway)
Дата:
Сообщение: Re: RFC: listing lock status