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: 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-01-16T17:52:11Z
Lists: pgsql-hackers
On Fri, Jan 16, 2026 at 9:14 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> * A hba line can be completely generic, which should be above DATABASE
> (ALTER DATABASE setting should override HBA setting, as it is more
> specific)

I think settings in the database should override the ones from the
HBA, yes. So that would put PGC_S_HBA right between, what, _ARGV and
_GLOBAL?

> The first choice seems more logical to me, as that's how pg_hba is
> usually used, but I thought this could still be confusing.

I agree it could be, but is it any more confusing than if you were to
set work_mem in postgresql.conf today, and then `ALTER ROLE ALL SET
work_mem` to something completely different?

Usability improvements for that should be made GUC-wide, I think, and
not influence the chosen order of operations for this feature (as long
as there are no new security concerns). I don't want any project
veterans, whether DBAs or maintainers, to be surprised by how a new
GUC context behaves.

--Jacob



Commits

  1. oauth: Allow validators to register custom HBA options

  2. Make LOAD of an already-loaded library into a no-op, instead of attempting