Horton

Re: Few untranslated error messages in OAuth

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-12-12T10:09:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. libpq: Align oauth_json_set_error() with other NLS patterns

  2. libpq-oauth: Don't translate internal errors

  3. libpq: Add missing OAuth translations

Hello,

These patches look good to me.

On 2025-Dec-11, Jacob Champion wrote:

> Oh, those catch logic errors in the parsing engine. v3-0002 removes
> those from the translation files as well.

Sounds good.

> On Thu, Nov 27, 2025 at 10:24 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > 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

Hmm, okay.

> 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.
>
> [1] https://www.postgresql.org/message-id/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com

Sure, no objections to that plan.  I'd say these messages are probably
among the most important ones to translate in the OAuth support in
libpq, because as I understand some of them are more likely to become
part of a GUI that an end-user interacts with.  But I have no quarrels
with it all waiting until a later release.  (After all, early adopters
are going to force English on themselves anyway.)

No strong opinion on JSONAPI_USE_PQEXPBUFFER.  As far as I can tell, we
pretty much force you to link libpq if you want to have a PQExpBuffer,
which tells me that a frontend jsonapi.c user would already be forced to
link libpq.  So they will also have libpq_gettext().  So maybe a dual
answer is realistic -- no need to consider a third case of frontend
jsonapi.c without libpq.  If somebody in the future wants to use
jsonapi.c without libpq, they can do the translation API fix work then.

> 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.

Yeah, I'd prefer that.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)