| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| 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-13 18:30:13 |
| Message-ID: | 736307.1791916213@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
shihao zhong <zhong950419(at)gmail(dot)com> writes:
>> 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.
> I missed that the server converts the query once more. If we want to
> keep the translation, v2-B fixes v1 for this. It sends a label that is
> not plain ASCII only when the locale encoding, client_encoding and
> server_encoding are all the same.
I think that restricting things like that would provide a reasonable
compromise between safety and losing translation altogether.
However, I don't like the details of v2-B at all. I think what
we need is more abstraction at the call sites, along the lines of
- printfPQExpBuffer(&buf, "/* %s */\n", _("Get matching aggregates"));
+ addQueryComment(&buf, gettext_noop("Get matching aggregates"));
where addQueryComment contains the logic to decide whether translation
is safe and then also adds the comment syntax. (Now I'm regretting
the decision to do it the other way before. I think the idea was to
leave room for the string to not be a constant; but we're not using
that flexibility, so giving it up seems okay.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-13 18:35:52 | Re: find_all_inheritors() with NoLock fails on concurrently dropped sub-partitions |
| Previous Message | Matthias van de Meent | 2026-10-13 18:08:30 | Re: Reducing relcache memory usage 2: shrink sizeof(RelationData) |