Re: [HACKERS] Optional message to user when terminating/cancelling backend - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Optional message to user when terminating/cancelling backend
Date
Msg-id CAFj8pRD=EL--HVY_a4-pFqr0U5UBRNOnVEGom2cSRvZs0+9L6Q@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Optional message to user when terminating/cancellingbackend  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: [HACKERS] Optional message to user when terminating/cancellingbackend
List pgsql-hackers


2018-08-12 0:17 GMT+02:00 Daniel Gustafsson <daniel@yesql.se>:
> On 6 Aug 2018, at 09:47, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> Has there been any consideration to encodings?

Thats a good point, no =/

> What happens if the message contains non-ASCII characters, and the sending backend is connected to database that uses a different encoding than the backend being signaled?

In the current state of the patch, instead of the message you get:

    FATAL: character with byte sequence 0xe3 0x82 0xbd in encoding "UTF8" has
           no equivalent in encoding “ISO_8859_5"

Where this code fails? Isn't somewhere upper where string literals are translated? Then this message is ok.
 

Thats clearly not good enough, but I’m not entirely sure what would be the best
way forward.  Restrict messages to only be in SQL_ASCII?  Store the encoding of
the message and check the encoding of the receiving backend before issuing it
for a valid conversion, falling back to no message in case there is none?
Neither seems terribly appealing, do you have any better suggestions?

The client<->server encoding translation should do this work no?

Regards

Pavel


cheers ./daniel

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] proposal: schema variables
Next
From: Noah Misch
Date:
Subject: Re: libpq should not look up all host addresses at once