Re: [HACKERS] Optional message to user when terminating/cancelling backend
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Onder Kalaci <onder@citusdata.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-08-12T08:54:55Z
Lists: pgsql-hackers
2018-08-12 10:29 GMT+02:00 Daniel Gustafsson <daniel@yesql.se>: > > On 12 Aug 2018, at 07:42, Pavel Stehule <pavel.stehule@gmail.com> wrote: > > 2018-08-12 0:17 GMT+02:00 Daniel Gustafsson <daniel@yesql.se <mailto: > daniel@yesql.se>>: > > > On 6 Aug 2018, at 09:47, Heikki Linnakangas <hlinnaka@iki.fi <mailto: > hlinnaka@iki.fi>> wrote: > > > > 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. > > This happens for example when a UTF-8 backend sends a message with japanese > characters to a backend using ISO_8859_5. So the code works as expected, > but > it’s not a very good user experience. > It is same like any other using of string literal. Personally, I don't think so these functions should be a exception. Pavel > cheers ./daniel
Commits
-
Refactor user-facing SQL functions signalling backends
- 09921f397b84 12.0 landed
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 cited