public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zsolt Parragi <[email protected]>
To: Nikolay Shaplov <[email protected]>
Cc: Álvaro Herrera <[email protected]>
Cc: Jacob Champion <[email protected]>
Cc: VASUKI M <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: [email protected]
Cc: Robert Haas <[email protected]>
Cc: [email protected]
Subject: Re: Custom oauth validator options
Date: Wed, 4 Feb 2026 11:42:12 +0000
Message-ID: <CAN4CZFMGwGdMnxP07Rk2qrC9eGQt31Lrerrnk66vQuzRhDEwiw@mail.gmail.com> (raw)
In-Reply-To: <CAN4CZFMCh3vOWGPbU5pTB-bwnoAtgFuDJmGGv7z7xeez+WJiag@mail.gmail.com>
References: <CAN4CZFPmF9fGOcFubwOxqXymhVo_RvbUx3bLoYQcfk=f0mwECw@mail.gmail.com>
<[email protected]>
<CAN4CZFPUfTj-BF-m5=F7_MnY_T3+Qh-DuG7N7ojdbJDkT8JHeA@mail.gmail.com>
<[email protected]>
<CAN4CZFMCh3vOWGPbU5pTB-bwnoAtgFuDJmGGv7z7xeez+WJiag@mail.gmail.com>
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.
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Custom oauth validator options
In-Reply-To: <CAN4CZFMGwGdMnxP07Rk2qrC9eGQt31Lrerrnk66vQuzRhDEwiw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox