shihao zhong <[email protected]> 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
