Re: Few untranslated error messages in OAuth
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Daniel Gustafsson <daniel@yesql.se>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-11T22:59:36Z
Lists: pgsql-hackers
Attachments
- v3-0001-libpq-Add-missing-OAuth-translations.patch (application/octet-stream) patch v3-0001
- v3-0002-libpq-oauth-Don-t-translate-internal-errors.patch (application/octet-stream) patch v3-0002
- v3-0003-libpq-Align-oauth_json_set_error-with-other-NLS-p.patch (application/octet-stream) patch v3-0003
On Thu, Nov 27, 2025 at 10:24 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> I gave these a quick look, and they look correct to me. I didn't test
> the resulting libpq though.
Thanks for the review!
> Of those, as an example,
> this one caught my attention for strange wording,
> "internal error: field \"%s\" still active at end of object"
> I think it means we haven't seen the closing quote at the end of the
> field, right? Maybe say something like "unterminated field \"%s\" ..."?
Oh, those catch logic errors in the parsing engine. v3-0002 removes
those from the translation files as well.
> There's also the strings in CHECK_MSETOPT and siblings macros missing
> quotes -- should be
> "failed to set \"%s\" on OAuth connection: %s"
Personally I prefer bare %s there, since it's an option name. Compare
setsockopt(SO_REUSEADDR) failed
failed to set CURLMOPT_SOCKETDATA on OAuth connection
> You're right, that's no good. We could try to define a new macro (maybe
> jsonapi_gettext()) that does stock _() on backend but libpq_gettext() on
> frontend ... but that wouldn't work nicely for frontend users other than
> libpq. Maybe something like
>
> #ifndef jsonapi_gettext
> #ifdef FRONTEND
> #define jsonapi_gettext(msg) libpq_gettext(msg)
> #else
> #define jsonapi_gettext(msg) gettext(msg)
> #endif
> #endif
>
> so any callers that want a third definition can just define it
> themselves in the compile line?
Yeah, the pattern should probably follow that of the
JSONAPI_USE_PQEXPBUFFER conditionals. I think I'll defer this until
after [1]; otherwise I might need to solve it twice. 0004 has been
dropped from the set.
On Thu, Nov 13, 2025 at 4:58 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> I assume translation changes such as these are generally
> backportable?
For now, I'll proceed as if a backport to 18 is appropriate for these.
Thanks again!
--Jacob
[1] https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
libpq: Align oauth_json_set_error() with other NLS patterns
- 7a15cff1f111 18.2 landed
- f7fbd02d32c4 19 (unreleased) landed
-
libpq-oauth: Don't translate internal errors
- aac25567fec1 18.2 landed
- 301a1dcf00c8 19 (unreleased) landed
-
libpq: Add missing OAuth translations
- 169ff4ca930b 18.2 landed
- ea3370b18ebe 19 (unreleased) landed