| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: [PG19] psql backslash commands fail with translated messages and a non UTF-8 client encoding |
| Date: | 2026-10-13 07:54:51 |
| Message-ID: | CAHGQGwF41qvKF5HHwwQPgutgBmJ1QpN=L7OXGFpNLVkQerLHUg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 13, 2026 at 1:26 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> 0001 sends the query without the label when the label is not plain
> ASCII and the locale encoding differs from client_encoding. In every
> other case the label is sent as before, and -E always shows it.
I'm not sure how useful it is to translate query labels. Isn't it simpler and
safer to leave them untranslated, ensuring that they contain only ASCII
characters?
The v1 approach of comparing the locale encoding with client_encoding
doesn't seem sufficient to determine whether a translated label is safe to
send. For example, with a Japanese UTF-8 locale and client_encoding=UTF8,
the patch would still send a Japanese label to a LATIN1 database, where
conversion to the database encoding would fail.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Gustafsson | 2026-10-13 07:59:26 | Re: [PATCH v1] Fix tab completion for concurrent materialized view refresh |
| Previous Message | vignesh C | 2026-10-13 07:41:16 | Re: Test publication.sql racing with subscription.sql might fail due to cache lookup error |