On Mon, Jan 26, 2026 at 4:06 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Wouldn't it be simpler to do all that validation at the server side,
> and for libpq to simply compare that what the user specified for the
> connection and what the server sent are the same?
No, I don't think so. That opens up the possibility of a third-party
server implementation breaking the OAUTHBEARER rules and libpq failing
to call them out on it.
> My question should have been: shouldn't the plugin api work at the
> SASL level instead of a specific OAuth level?
IMO, yes, but I don't imagine that most people want to pick a SASL
plugin to switch OAuth flows. They just want their flow to match the
use case and move on.
> Or even if the first
> iteration of the internal API would only allow it to modify the OAuth
> flow, shouldn't the public facing configuration (env var / connection
> string / anything) be something more generic?
I think these are two different use cases that _could_ be handled with
the same knob but probably _should_ not be (see above).
> How, and when would I use this (oauth limited, differently configured)
> plugin API instead of the authdata hook? And I can't think of any good
> use cases outside the command line tools included with postgres.
That's exactly the use case. (Also, library clients of postgres that
should not install application hooks, other monolithic utilities that
link against libpq, etc.) Who wants to recompile their clients just to
switch how they get a token?
--Jacob
