Skip site navigation (1) Skip section navigation (2)

Re: encoding of PostgreSQL messages

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Karsten Hilbert" <Karsten(dot)Hilbert(at)gmx(dot)net>
Subject: Re: encoding of PostgreSQL messages
Date: 2009-01-01 18:33:56
Message-ID: 200901012033.57020.peter_e@gmx.net (view raw or flat)
Thread:
Lists: pgsql-general
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.

In response to

Responses

pgsql-general by date

Next:From: Berend ToberDate: 2009-01-02 00:27:33
Subject: Re: manage changes to views having depencies
Previous:From: Martin GaintyDate: 2009-01-01 14:36:22
Subject: Re: How to cast a general record?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group