Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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,

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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:

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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 >

Re: [HACKERS] handling unconvertible error messages

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 >

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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,

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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

Re: [HACKERS] handling unconvertible error messages

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: > >

[HACKERS] handling unconvertible error messages

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: character with byte sequence 0xd0 0x9e in encoding "UTF8"