Re: Few untranslated error messages in OAuth

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Few untranslated error messages in OAuth
Date: 2025-12-11 22:59:36
Message-ID: CAOYmi+=n8xD92MebjCA0p2ceWeTszZHUE+0x+_6pgYWXpg0nBA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 27, 2025 at 10:24 AM Álvaro Herrera <alvherre(at)kurilemu(dot)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(dot)champion(at)enterprisedb(dot)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

Attachment Content-Type Size
v3-0001-libpq-Add-missing-OAuth-translations.patch application/octet-stream 7.1 KB
v3-0002-libpq-oauth-Don-t-translate-internal-errors.patch application/octet-stream 10.1 KB
v3-0003-libpq-Align-oauth_json_set_error-with-other-NLS-p.patch application/octet-stream 5.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2025-12-11 23:12:26 Re: Proposal: Add a callback data parameter to GetNamedDSMSegment
Previous Message Chao Li 2025-12-11 22:49:03 Re: Improve pg_sync_replication_slots() to wait for primary to advance