MIME-Version: 1.0
References: 
 <CAN4CZFPmF9fGOcFubwOxqXymhVo_RvbUx3bLoYQcfk=f0mwECw@mail.gmail.com>
 <202601281620.m3hrqtih5b2w@alvherre.pgsql>
 <CAN4CZFPUfTj-BF-m5=F7_MnY_T3+Qh-DuG7N7ojdbJDkT8JHeA@mail.gmail.com>
 <fd412b8e-fab5-43fe-b18d-3e035e4998a7@nataraj.su>
 <CAN4CZFMCh3vOWGPbU5pTB-bwnoAtgFuDJmGGv7z7xeez+WJiag@mail.gmail.com>
 <CAN4CZFMGwGdMnxP07Rk2qrC9eGQt31Lrerrnk66vQuzRhDEwiw@mail.gmail.com>
 <CAOYmi+nTXGcroZD_Mnkc8LYWYFbfDYNR4ML_yQ5sF9+DY2amcg@mail.gmail.com>
 <CAN4CZFMxQzFD0ZJS7pX5Ajdei7TmpROEZKG5vxmfmhCQEQX3fA@mail.gmail.com>
In-Reply-To: 
 <CAN4CZFMxQzFD0ZJS7pX5Ajdei7TmpROEZKG5vxmfmhCQEQX3fA@mail.gmail.com>
From: Jacob Champion <jacob.champion@enterprisedb.com>
Date: Fri, 27 Mar 2026 16:03:00 -0700
Message-ID: 
 <CAOYmi+mUdsTODm0F8PWBQYcCQPBKvHUAieXgoP1pWXtEA2N9Aw@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Nikolay Shaplov <dhyan@nataraj.su>,
 =?UTF-8?Q?=C3=81lvaro_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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAOYmi%2BmUdsTODm0F8PWBQYcCQPBKvHUAieXgoP1pWXtEA2N9Aw%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 23, 2026 at 2:45=E2=80=AFPM Zsolt Parragi <zsolt.parragi@percon=
a.com> wrote:
> This is my only concern with this patch: since we have a list
> separated validatr names as a GUC already, couldn't we require a
> <validator_name>. prefix instead of the fixed "validator.", to keep
> the hba configuration consistent with gucs?

Well, the `validator.` prefix lets us end-run the namespace issue [1].
It's one thing if I claim that single prefix in parse_hba_auth_opt();
it's another thing if I camp out on literally every identifier
containing a dot.

I'm also not convinced that it's worth spending additional code here
to decide _which_ of the blessed validators is in force for the
current line. (Deferring the check of the option names is bad enough,
but there appears to be no way around that.)

> Validators would still have to handle these options differently, but
> at least it would look consistent from the user perspective - global
> setting in postgresql.conf, same hba-line specific override in
> pg_hba.conf. (also, validators already added global GUCs in pg18, and
> this would also keep it consistent with that)

After the wild goose chase I sent you on, I think
consistency-in-form-but-not-function is more likely to be a liability
than a benefit. Sure, validator authors will be able to pretend that
users can override particular GUCs per-line, but that's not what's
actually happening, so that could increase user confusion and support
burden for very little practical upside. (As one example, `SHOW
my_validator.setting` isn't going to behave intuitively.)

Since my pitch here is "this is an architectural dead end, but it'll
get us moving while we pursue the better route," I prefer something
that's very obviously bespoke. Especially since validators will have
to migrate from the old way to the new way, if we get our wish. I
don't really want anyone to spend time resolving the collision of the
two behaviors; I'd rather just let the old ugly configuration solution
wither (or die), and encourage everyone to switch as rapidly as
possible.

> + REQUIRE_AUTH_OPTION(uaOAuth, name, "oauth");
>
> Shouldn't this check go before the name validation?

Yeah, I agree. (My original code had a more generic error message when
the name check failed, but now that the message is OAuth-specific, I
don't think it makes sense to pretend that it could belong to any
other auth method.)

Thanks!
--Jacob

[1] https://postgr.es/m/CAOYmi%2Bn9%2BVDNayxsZuG30YLxOXrVB2Wu%3DjBR4WrEdJvx=
jTATKw%40mail.gmail.com