public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jacob Champion <[email protected]>
To: Andreas Karlsson <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: [oauth] Per connection auth hooks in libpq
Date: Thu, 26 Feb 2026 16:42:43 -0800
Message-ID: <CAOYmi+k4wViip45Qi3Hc45EmzDWSCUhvgb5Os-gSgYavq3goFQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

On Thu, Feb 26, 2026 at 3:36 PM Andreas Karlsson <[email protected]> wrote:
> So attached is a proof of concept patch which implements a
> per-connection hook. It is just a rough patch to start a discussion. If
> people like it I can clean it up and add tests and documentation.

Thank you! So let me start by saying I agree that global is bad, and
per-connection is what we would ideally allow. The original patchset
started out with per-connection settings (for what eventually became
PQAUTHDATA_PROMPT_OAUTH_DEVICE, if I recall correctly).

But I quickly ran into chicken-and-egg problems. We don't expose the
ability to get a connection handle before the connection attempt
starts, nor do we expose the ability to synchronously finish a
connection that's already been started. (So you're locked into
polling-only if you want this.)

You can argue that PQconnectStart() *currently* always returns before
writing its first data, but I feel uncomfortable pinning that
implementation detail for OAuth alone (unless the senior maintainers
are fine with it?). It's already odd, in my mind, that we return
before knowing that polling is even necessary, and I think somebody
might reasonably change that (on purpose, or not) in the future,
especially if PQconnectPoll() ever gets rewritten like I'm hoping.

Not providing a clear "setopt" operation on an empty PGconn is
reminding me of my complaint that we put both application settings and
network settings into the connection string [1], which is reminding me
of Zsolt's complaint that it's difficult to establish security
boundaries for connection settings in the face of environment
variables [2], which recalls earlier discussions with Tom around
sslkeylogfile [3]. This is like an evil twin to the HBA-setting
problem. I think ideally these _would_ be solved with a single
coherent plan, but is there a way to tackle it incrementally...?

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BnQu-X7rL3GAB%3Dz2p7qLS4RrNARsz5VSagx%3D3q%2Bh_03zg%40mail.gmail.com
[2] https://postgr.es/m/CAOYmi%2BmVX5rKfvsCVVYM8ZDEBaNDO83TBLPURFuEgA8gbsU8Zw%40mail.gmail.com
[3] https://postgr.es/m/1774813.1736385450%40sss.pgh.pa.us

view thread (2+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: [oauth] Per connection auth hooks in libpq
  In-Reply-To: <CAOYmi+k4wViip45Qi3Hc45EmzDWSCUhvgb5Os-gSgYavq3goFQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox