Re: encoding of PostgreSQL messages - Mailing list pgsql-general

From Bruce Momjian
Subject Re: encoding of PostgreSQL messages
Date
Msg-id 200901220110.n0M1AWY03839@momjian.us
Whole thread Raw
In response to Re: encoding of PostgreSQL messages  (Karsten Hilbert <Karsten.Hilbert@gmx.net>)
Responses Re: encoding of PostgreSQL messages  (Hiroshi Inoue <inoue@tpf.co.jp>)
List pgsql-general
Added to TODO:

    Improve encoding of connection startup messages sent to the client

        Currently some authentication error messages are sent in the server
        encoding

            * http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php
            * http://archives.postgresql.org/pgsql-general/2009-01/msg00005.php

---------------------------------------------------------------------------

Karsten Hilbert wrote:
> Bruce, et al,
>
> given the thread partially quoted below would this warrant a
> TODO item "improve communication of encoding between client
> and server regarding early startup messages" ?
>
> A very usable band-aid for 8.4 - short of a proper fix -
> would be the minimal-invasive sending of messages in 7-bit
> English until server_encoding can be retrieved by the client
> by current means.
>
> Thanks,
> Karsten
>
> On Thu, Jan 01, 2009 at 08:33:56PM +0200, Peter Eisentraut wrote:
> > Subject: Re: [GENERAL] encoding of PostgreSQL messages
> > User-Agent: KMail/1.9.9
> >
> > On Wednesday 31 December 2008 20:23:47 Tom Lane wrote:
> > > > The proper fix is probably to include the client encoding in the
> > > > connection startup message.
> > >
> > > What of errors occurring before such an option could be applied?
> >
> > Connection errors are handled by the client, which knows the client encoding.
> > If the setting of the client encoding would be one of the first things to be
> > done on the server side, you would only have a handful of possible error
> > conditions left (e.g., setlocale failed, out of memory).  You could choose to
> > report those in plain ASCII or send a special error code that the client can
> > resolve.  Although I guess no one could fault us if "could not set language"
> > is reported not translated. ;-)
> >
> > > I think that ultimately it's necessary to accept that there will be some
> > > window during connection startup where sending plain ASCII (English)
> > > messages is the best recourse.
> >
> > Ultimately yes.  But we currently handle the client encoding quite late in the
> > startup sequence so that many connection startup failure messages that are of
> > interest to normal users would likely be affected.  So moving the client
> > encoding handling to the earliest possible phase would still be desirable.
> >
> > --
> > Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-general
>
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Automatic CRL reload
Next
From: Hannu Krosing
Date:
Subject: Re: [Plproxy-users] A complex plproxy query