Re: encoding of PostgreSQL messages

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: encoding of PostgreSQL messages
Date: 2009-01-07 19:15:50
Message-ID: 20090107191550.GE3833@merkur.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gerhard Heift 2009-01-07 20:16:04 Re: stable function called for every row?
Previous Message Mohamed 2009-01-07 19:07:44 to_tsquery, plainto_... avoiding bad input, injections. Is there a builtin function for this ? Escaping?