MIME-Version: 1.0
References: <16a91d02795cb991963326a902afa764e4d721db.camel@gmail.com>
 <3D82D240-1CC5-4CE6-BE30-6065B693D40C@yesql.se> <CAOYmi+=fbZNJSkHVci=GpR8XPYObK=H+2ERRha0LDTS+ifsWnw@mail.gmail.com>
 <CAN4CZFPhm2NCRWzZpX=kRLqyxu4Ps-d0xE5W75a-iDoKrLbXBw@mail.gmail.com>
 <CAOYmi+=HcXJub1rDsQ7vpKMHuBB6NTA2Z5T=zAkaFdRThf+9zg@mail.gmail.com>
 <b08bf613bba131eaf15ac163d84604db452d4fde.camel@gmail.com>
 <CAOYmi+mMx1DnNpKG8RdknH0-GuPR9jv+G9r2iFND=Yve7DOF6g@mail.gmail.com> <7a0464f0c05db689eb97ba963b212d477d03f5a3.camel@gmail.com>
In-Reply-To: <7a0464f0c05db689eb97ba963b212d477d03f5a3.camel@gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Mon, 5 Jan 2026 10:37:45 -0800
Message-ID: <CAOYmi+nQawWHzC4mRhJnzZzzqjnUDg-yxN3f3ZqPX=+jpKU+zg@mail.gmail.com>
Subject: Re: Make PGOAUTHCAFILE in libpq-oauth work out of debug mode
To: "Jonathan Gonzalez V." <jonathan.abdiel@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>, Daniel Gustafsson <daniel@yesql.se>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAOYmi%2BnQawWHzC4mRhJnzZzzqjnUDg-yxN3f3ZqPX%3D%2BjpKU%2Bzg%40mail.gmail.com>
Precedence: bulk

On Sat, Dec 20, 2025 at 9:53=E2=80=AFAM Jonathan Gonzalez V.
<jonathan.abdiel@gmail.com> wrote:
> > > > https://wiki.postgresql.org/wiki/Proposal:_Promote_PGOAUTHCAFILE_to=
_feature
> > >
> > > How can we work on that? because of the above it may be required to
> > > add
> > > even more possibilities.
> >
> > Not sure what you mean. I think we're working on it now, in this
> > thread?
>
> Yes, but having a list of ideas listed, that we all can read may make
> sense, that's because following the threads with all the ideas at once
> it's a big difficult some times!

See https://wiki.postgresql.org/wiki/Category:OAuth_Working_Group for
a current list of tagged [oauth] proposals. Or is that not what you're
asking about?

> In my opinion, "debug" it's not just developers, [...]
> since all the systems now days can run on hundreds
> of servers or containers, no one looks into the logs manually, you have
> automated system for it, that will read, parse, collect and distribute
> your logs into different storage, databases(even PostgreSQL database
> can be used for it) or display system. It is for theses cases that
> having something that can be parsed is always useful.

Sure, but that's not the use case for PGOAUTHDEBUG. It's fine to
develop a feature that handles production logging for client
authentication details -- it's just emphatically not what that envvar
was designed to do. This is a developer feature which turns out to be
hiding another feature that people want to use in production today.

I know the most visible aspect of PGOAUTHDEBUG=3DUNSAFE is the logging
spray, so that might have contributed to the confusion.

> Well, I think I was misunderstood here, when I was talking about "debug
> levels" I was talking about logs debug levels

Right, and I'm not. I guess that's the main disconnect here: I'm only
talking about enabling and disabling the features exposed by
PGOAUTHDEBUG. I don't think a debug level helps with that, which is
why I proposed a bitmap.

But that's a feature for a different thread name. I think we should
continue this one by adding an oauth_ca_file connection parameter and
documentation, including the default behavior (which defers to Curl).

--Jacob