On Sat, 13 Aug 2016 12:02:30 -0400
Tom Lane wrote:
> Victor Wagner 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
Tom> while giving something at least passable in the cases
that are broken today.
Would you mind adding an explicit "encoding" field to the error message?
At least it would give clear explanation how to parse that message without
resorting to a guess dance.
The biggest problem is client has no id
Victor Wagner 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 th
Victor>It is not a client job to convert encodings.
Of course.
However, there is a vast amount of old PG versions deployed in the wild
that send wrong data to clients.
This indeed makes bad user experience, so it is worth doing 2 things:
1) Implement proper solution in further PostgreSQL version
On Sat, 13 Aug 2016 09:24:47 +
Vladimir Sitnikov wrote:
> Victor>We don't have 190 message catalog translations in the
> Victor>PostgreSQL. So problem with encoding for messages is quite
> Victor>limited.
>
> Even though the number of translations is limited, there's a problem
> when trying
Victor>We don't have 190 message catalog translations in the PostgreSQL.
Victor>So problem with encoding for messages is quite limited.
Even though the number of translations is limited, there's a problem when
trying to tell one "one-byte-encoding" from another "one-byte" one.
It would be so much
On Wed, 10 Aug 2016 11:08:43 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> Hello,
>
> (I've recovered the lost Cc recipients so far)
>
> At Mon, 8 Aug 2016 12:52:11 +0300, Victor Wagner
> wrote in <20160808125211.1361c...@fafnir.local.vm>
> > On Mon, 08 Aug 2016 18:28:57 +0900 (Tokyo
Hello,
(I've recovered the lost Cc recipients so far)
At Mon, 8 Aug 2016 12:52:11 +0300, Victor Wagner wrote in
<20160808125211.1361c...@fafnir.local.vm>
> On Mon, 08 Aug 2016 18:28:57 +0900 (Tokyo Standard Time)
> Kyotaro HORIGUCHI wrote:
> >
> > I don't see charset compatibility to be easil
On Mon, 08 Aug 2016 18:28:57 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
>
> I don't see charset compatibility to be easily detectable,
In the worst case we can hardcode explicit compatibility table.
There is limited set of languages, which have translated error messages,
and limited (
On Mon, 08 Aug 2016 18:11:54 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
> At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro
> HORIGUCHI wrote in
> <20160808.171821.100221089.horiguchi.kyot...@lab.ntt.co.jp>
>
> Somewhat wrong. The core problem is the procedures offered
At Mon, 08 Aug 2016 18:11:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160808.181154.252052789.horiguchi.kyot...@lab.ntt.co.jp>
> At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
> <20160808.171821.100221089.horiguchi.kyot...@lab.ntt.co.j
On Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI wrote:
>
> I'm not sure what messages may be raised before authentication
> but it can be a more generic-solution. (Adding check during
> on-session.)
Definitely, there can be authentication error message, which is sent i
At Mon, 08 Aug 2016 17:18:21 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160808.171821.100221089.horiguchi.kyot...@lab.ntt.co.jp>
> Looking at check_client_encoding(), the comment says as following.
>
> | * If we are not within a transaction then PrepareClientEncoding will not
>
At Mon, 8 Aug 2016 10:19:10 +0300, Victor Wagner wrote in
<20160808101910.49bee...@fafnir.local.vm>
> On Fri, 5 Aug 2016 11:21:44 -0400
> Peter Eisentraut wrote:
>
> > On 8/4/16 2:45 AM, Victor Wagner wrote:
> > > 4. At the session startup try to reinitializie LC_MESSAGES locale
> > > category
On Fri, 5 Aug 2016 11:21:44 -0400
Peter Eisentraut wrote:
> On 8/4/16 2:45 AM, Victor Wagner wrote:
> > 4. At the session startup try to reinitializie LC_MESSAGES locale
> > category with the combination
> > of the server (or better client-send) language and region and
> > client-supplied encodin
On Fri, 5 Aug 2016 11:23:37 -0400
Peter Eisentraut wrote:
> On 8/4/16 9:42 AM, Tom Lane wrote:
> > I'm inclined to think that we should reset the message locale
> > to C as soon as we've forked away from the postmaster, and leave it
> > that way until we've absorbed settings from the startup pack
On 8/4/16 9:42 AM, Tom Lane wrote:
> I'm inclined to think that we should reset the message locale
> to C as soon as we've forked away from the postmaster, and leave it
> that way until we've absorbed settings from the startup packet.
> Sending messages of this sort in English isn't great, but it's
On 8/4/16 2:45 AM, Victor Wagner wrote:
> 4. At the session startup try to reinitializie LC_MESSAGES locale
> category with the combination
> of the server (or better client-send) language and region and
> client-supplied encoding, and if this failed, use untranslated error
> message. Obvoisly, att
On Thu, 04 Aug 2016 14:25:52 -0400
Tom Lane wrote:
> Victor Wagner writes:
> > Really, if this response is sent after backend has been forked,
> > problem probably can be easily fixed better way - StartupMessage
> > contain information about desired client encoding, so this
> > information just
Victor Wagner writes:
> On Thu, 04 Aug 2016 09:42:10 -0400
> Tom Lane wrote:
>> Yeah. I'm inclined to think that we should reset the message locale
>> to C as soon as we've forked away from the postmaster, and leave it
>> that way until we've absorbed settings from the startup packet.
> Really,
On Thu, 04 Aug 2016 09:42:10 -0400
Tom Lane wrote:
> Victor Wagner writes:
> > If error occurs during processing of StartMessage protocol message,
> > i.e. client request connection to unexisting database,
> > ErrorResponse would contain message in the server default locale,
> > despite of clien
Victor Wagner writes:
> If error occurs during processing of StartMessage protocol message,
> i.e. client request connection to unexisting database,
> ErrorResponse would contain message in the server default locale,
> despite of client encoding being specified in the StartMessage.
Yeah. I'm inc
On Mon, 25 Jul 2016 10:43:44 -0400
Peter Eisentraut wrote:
e is
> a real error message, but it could not be converted.
>
> I think ideally we could make this better in two ways:
>
> 1) Send the original error message untranslated. That would require
> saving the original error message in errms
On Mon, 25 Jul 2016 10:43:44 -0400
Peter Eisentraut wrote:
> Example: I have a database cluster initialized with
> --locale=ru_RU.UTF-8 (built with NLS). Let's say for some reason, I
> have client encoding set to LATIN1. All error messages come back
> like this:
>
> test=> select * from notthe
Hello,
At Wed, 27 Jul 2016 19:53:01 +0800, Craig Ringer wrote
in
> On 25 July 2016 at 22:43, Peter Eisentraut > wrote:
>
> > Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
> > (built with NLS). Let's say for some reason, I have client encoding set
> > to LATIN1. Al
On 25 July 2016 at 22:43, Peter Eisentraut wrote:
> Example: I have a database cluster initialized with --locale=ru_RU.UTF-8
> (built with NLS). Let's say for some reason, I have client encoding set
> to LATIN1. All error messages come back like this:
>
> test=> select * from notthere;
> ERROR:
26 matches
Mail list logo
