Re: Few untranslated error messages in OAuth

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(at)kurilemu(dot)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(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.

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)