Re: [PG19] psql backslash commands fail with translated messages and a non UTF-8 client encoding

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>
Subject: Re: [PG19] psql backslash commands fail with translated messages and a non UTF-8 client encoding
Date: 2026-10-14 04:45:17
Message-ID: CAGRkXqSpGyaeU0Q_Dp-ZDdHPMJBKPquFm6N=m9KTUNe_8GFsRQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> * It occurred to me that we could avoid all the gettext_noop()
> decorations by adding addQueryComment to GETTEXT_TRIGGERS.

Done in v4. The call sites now pass a plain string. The msgids that
xgettext extracts are the same as on master.

> Should we invert the logic to avoid a useless gettext lookup?

Yes. v4 checks the encodings first and calls gettext only when they
match. On Windows it never looks the label up. The one thing we lose
is a translation that happens to be plain ASCII when the encodings
differ.

> * Do we actually need to test for OUTPUT_CHARSET, given that
> this code doesn't execute on Windows?

Yes. glibc honors it too. On Ubuntu 24.04 with glibc 2.39,
a ja_JP.UTF-8 locale and a UTF8 database, an unpatched psql 19 works,
and with OUTPUT_CHARSET=EUC-JP it fails:

ERROR: invalid byte sequence for encoding "UTF8": 0xc2 0xd0

v4 uses the English label in that case.

Thanks,
Shihao

Attachment Content-Type Size
v4-0001-psql-Fall-back-to-English-for-unsafe-hidden-query-REL_19_STABLE.patch.txt text/plain 34.8 KB
v4-0001-psql-Fall-back-to-English-for-unsafe-hidden-query.patch application/octet-stream 34.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou 2026-10-14 04:58:42 Re: Proposal: Conflict log history table for Logical Replication
Previous Message shihao zhong 2026-10-14 04:39:17 Re: pgsql: Don't trust NOT NULL on virtual generated columns of partitioned