Re: handling unconvertible error messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: handling unconvertible error messages
Date: 2016-08-13 16:02:30
Message-ID: 677.1471104150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Victor Wagner <vitus(at)wagner(dot)pp(dot)ru> writes:
> I think it is better to avoid such a problem and fix system so server
> would never send a message in the encoding, different from client one.

Don't hold your breath waiting for that to happen.

Quite aside from the question of whether we want to trust GUC settings
from the startup packet before we've authenticated the user, there's a
small problem that the server *can't* translate *any* encoding until
it's successfully connected to a database and is able to read the
pg_conversion catalog.

We might be able to institute some rule like "examine the startup
packet and see if it specifies a client_encoding different from what
we inherited from the postmaster. If not, continue with current
behavior (send messages localized per postmaster's settings). If so,
fall back to English messages/C locale until startup is complete."
This would preserve current functionality in cases where it actually,
er, functions, while giving something at least passable in the cases
that are broken today.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-08-13 16:25:59 Re: handling unconvertible error messages
Previous Message Alvaro Herrera 2016-08-13 15:56:51 Re: max_parallel_degree > 0 for 9.6 beta