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>
In-Reply-To: <CAN4CZFMCh3vOWGPbU5pTB-bwnoAtgFuDJmGGv7z7xeez+WJiag@mail.gmail.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 4 Feb 2026 11:42:12 +0000
Message-ID: <CAN4CZFMGwGdMnxP07Rk2qrC9eGQt31Lrerrnk66vQuzRhDEwiw@mail.gmail.com>
Subject: Re: Custom oauth validator options
To: Nikolay Shaplov <dhyan@nataraj.su>
Cc: =?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>, 
	Jacob Champion <jacob.champion@enterprisedb.com>, 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"
Archived-At: <https://www.postgresql.org/message-id/CAN4CZFMGwGdMnxP07Rk2qrC9eGQt31Lrerrnk66vQuzRhDEwiw%40mail.gmail.com>
Precedence: bulk

I've looked into the patch in more detail. (I will post a review later
to that thread, I have some notes I have to format properly)

As for this use case, we could use this (for my original B or C
options), but I see a potential problem:

First, we either only use this code to feed the unknown parameters to
the options parser, and keep the existing hba options parser as is for
the hardcoded parameters. Or also include the fixed options in it, so
that everything works exactly the same.

Then we either make it limited to oauth validators, or try to keep it
generic for any session_preload_libraries.

If we only use this for unknown options, and limit it to oauth
validators, then options.h/c could work as is.

If we want to implement anything more generic, we'll face issues, as
the current API only supports validating the input once. In the most
generic case:

* Parsing the core hba options in postmaster
* Validating core options, ignoring unknowns
* Loading the oauth validator
* Validating options again, as the validator needs its custom options
- having unknown remaining options is still valid
* Running the validator
* Loading session preload libraries
* Validating options again - unknown options are an error now

So up to 3 times, and it also needs a way for extensions to edit spec
sets. (In the simple case, only the validator has to know about that)

I think this makes this impractical for the more complex applications,
but if we want to go back to the minimal original concept, limited to
oauth validators, it could work. I'm also not sure how useful this
non-GUC API would be for extensions other than validators, which also
tells me that this version should be limited to the validators.

Also, this isn't an approach with an easy way to convert it into
PGC_HBA, as it requires a clearly different api in the validator - I
don't see a nice way to do that without changing the API used by the
validators.