Re: Custom oauth validator options
Jacob Champion <jacob.champion@enterprisedb.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Nikolay Shaplov <dhyan@nataraj.su>, Álvaro Herrera <alvherre@kurilemu.de>, VASUKI M <vasukianand0119@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, david.g.johnston@gmail.com, Robert Haas <robertmhaas@gmail.com>, myon@debian.org
Date: 2026-04-06T22:16:55Z
Lists: pgsql-hackers
On Mon, Apr 6, 2026 at 3:09 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote: > > I believe this is now a complete patch > > proposal; tear it apart. :D > > The patch looks good to me as is, I don't see any real issues with it, Great! I am prepping for a commit Sometime Very Soon. > maybe one cosmetic question in the test. > > + if (GetOAuthHBAOption(state, "log")) > + elog(LOG, "%s", GetOAuthHBAOption(state, "log")); > + > > If we treat the test code as an example for real implementations, (It's not, though -- my test code is frequently abusive on purpose and should not be used as best-practice. If we want compilable sample code, that looks different from tests IMHO.) > this > and the other use could cache the option in a local variable instead > of making duplicate calls, following the pattern of the documentation. In this case, I want the test to pin the behavior that multiple calls should work as you'd expect. Thanks, --Jacob
Commits
-
oauth: Allow validators to register custom HBA options
- b977bd308a09 19 (unreleased) landed
-
Make LOAD of an already-loaded library into a no-op, instead of attempting
- 602a9ef5a7c6 9.0.0 cited