Horton

Thread

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

  1. Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-02T13:05:49Z

    Hello hackers,

The current OAuth code allows validators to add custom validation
logic, but does not allow them to introduce custom
authentication-related parameters in the place where they belong:
pg_hba.conf. As a workaround, both pg_oidc_validator and
postgres-keycloak-oauth-validator (and likely others; these are simply
the two I know of) rely on GUC variables instead.

I see two issues with this:

1. Configuration for OAuth validation ends up split across two
locations: issuer/scope and a few other parameters are defined in
pg_hba.conf, while custom parameters must be set in postgresql.conf.

2. We have received multiple questions asking how to configure
multiple OIDC servers with different parameter sets. I am not sure how
common it is to use multiple OAuth providers with a single PostgreSQL
instance, but the question is certainly reasonable.

Given this, I would like to ask what you think about making
pg_hba.conf extensible. At present, option parsing is hardcoded in
parse_hba_auth_opt, and any unknown parameter triggers an error at the
end of the function.

I can see a few possible approaches:

a. Add an OAuth-specific hook that allows injecting additional
option-parsing logic into this function, as part of the existing
OAuthValidatorCallbacks. This could be scoped to the validator used on
the specific HBA line, even if multiple validators are loaded.
b. Allow the existing startup callback to supply a list of additional
valid configuration names, with the validation callback responsible
for parsing and validating them.
c. Add a more generic hook usable by any extension. I do not currently
have concrete use cases outside OAuth, but perhaps others do.

I would be interested in your thoughts on whether an improvement in
this area would be useful.

I also have two related questions, which might be addressed as part of
the above or independently:

1. HBA options are parsed sequentially. If validator-specific options
are tied to a particular validator, this implies that validator=...
must appear before its parameters when multiple validators are loaded,
since we cannot otherwise determine which validator is used. Is this
acceptable behavior, or should options be allowed in any order?

2. If a validator introduces many options, an HBA line could become
very long and hard to read. Would it make sense to allow loading the
parameters for a given line from a separate file? This might already
be useful today: for example, if a long issuer URL is repeated across
several HBA lines, it could instead be defined once in an external
file and referenced multiple times.

  2. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-16T23:09:51Z

    Sorry for missing this thread!

On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> 1. Configuration for OAuth validation ends up split across two
> locations: issuer/scope and a few other parameters are defined in
> pg_hba.conf, while custom parameters must be set in postgresql.conf.

Yeah. (This has come up before a couple of times that I know of, in
the context of pg_hba and pg_ident splitting important configuration
between them [1], and in the context of SNI's proposed pg_hosts config
[2].)

> 2. We have received multiple questions asking how to configure
> multiple OIDC servers with different parameter sets. I am not sure how
> common it is to use multiple OAuth providers with a single PostgreSQL
> instance, but the question is certainly reasonable.

What kinds of parameters? Having a motivating use case would be
helpful; HBA isn't always as flexible as people assume and I want to
make sure that we can end with a usable feature.

> Given this, I would like to ask what you think about making
> pg_hba.conf extensible.

Your proposals (and the concerns they raise) seem reasonable enough at
first glance. (I still want a motivating use case, though.)

Honestly, I'd *prefer* that any solution not be OAuth-specific. I
might throw two alternatives onto the pile:

d. Have HBA plug into the GUC system itself

A hypothetical PGC_HBA context would seem to fit nicely between
PGC_SIGHUP and PGC_SU_BACKEND.

e. Subsume HBA, ident, (hosts,) etc. under postgresql.conf

This is my personal white whale. I think pg_hba+ident is no longer fit
for purpose. It makes nonexistent use cases easy and common use cases
unnecessarily difficult. Most people ignore half the columns. New
users are surprised that you can't choose between authentication
options. You have to correlate a bunch of different files with
differing syntaxes to figure out what is going on. Etc, etc.

This is why I bypassed pg_ident for validators, so that they could be
free to do useful stuff while the core caught up. But I didn't intend
to keep them separate forever.

(I'm only halfway serious with (e) -- I don't really intend to drive
your thread straight into a wall. But when I read proposals a-c, I get
the sinking feeling that this *should* be solved in a more radical
way, if we could only agree on a direction...)

Thanks,
--Jacob

[1] https://postgr.es/m/0e0c038ab962c3f6dab00934fe5ae1ae115f44c0.camel%40vmware.com
[2] https://postgr.es/m/CAOYmi%2B%3DZjGJLw8tCkzY88acd%3Dir1r8eAxO-%2B5wXm9gtCUV97Sg%40mail.gmail.com

  3. Re: Custom oauth validator options

    VASUKI M <vasukianand0119@gmail.com> — 2025-12-17T06:30:44Z

    Hi All,

The core issue,as you said,is that OAuth validators can add custom
validation logic,but they can't define their own authentication-related
parameters in pg_hba.conf,where they naturally belong.Because of
that,validator-specific config ends up pushed into postgresql.conf via
GUCs,which feels a bit awkward and scattered.

That leads to the same points you mentioned:

1]OAuth configuration gets split between pg_hba.conf and
postgres.conf,which is confusing to reason about.
2]using multiple OIDC/OAuth providers with different parameter sets on a
single Postgresql instance is hard(or effectively impossible),even though
it's a pretty reasonable use case.

Given the constraints of the current HBA model(and similar issues that
recently came up with SNI),I agree that anything involving generic
extensibility or nested configuration would be a big hammer and likely too
complex.

I also have two related questions, which might be addressed as part of
> the above or independently:
>
> 1. HBA options are parsed sequentially. If validator-specific options
> are tied to a particular validator, this implies that validator=...
> must appear before its parameters when multiple validators are loaded,
> since we cannot otherwise determine which validator is used. Is this
> acceptable behavior, or should options be allowed in any order?
>
> 2. If a validator introduces many options, an HBA line could become
> very long and hard to read. Would it make sense to allow loading the
> parameters for a given line from a separate file? This might already
> be useful today: for example, if a long issuer URL is repeated across
> several HBA lines, it could instead be defined once in an external
> file and referenced multiple times.
>
>
So the direction I'm most aligned with is option (b): letting OAuth
validator advertise a limited list of additional valid option names for
pg_hba.conf,while keeping parsing,ordering rules,and validation firmly in
core.That seems like the least spicy option-incremental,OAuth-scoped,and
not a redesign of HBA parsing.

Reg. ordering:requiring validator= to appear before validator-specific
options feels acceptable to me if this is pursued,since it keeps parsing
simple and avoids ambiguity.
Reg very long HBA lines: totally agree this is a real readability issue,but
allowing per-line includes or external file feels like a seperate(and much
bigger)topic,probably best tackled independently.

Overall, +1 that this limitation is real and worth discussing.I’ll plan to
send a patch shortly exploring option (b).

Regards,

Vasuki M
CDAC,Chennai.

  4. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-17T09:33:51Z

    > What kinds of parameters? Having a motivating use case would be
> helpful; HBA isn't always as flexible as people assume and I want to
> make sure that we can end with a usable feature.

One issue we have is that some providers don't allow users to select
what goes into the subject claim, but do allow users to define custom
claims. Additionally, the subject claim is sometimes a random
generated id, which gets generated on the first login to the client,
and that makes it practically unusable for pg. It would require:

* user trying to login to pg
* getting rejected
* figuring out what's the subject
* adding it to pg ident / some other config
* user can finally login

Instead we decided to let everyone configure which claim they want to
use for user mapping. But because of that, this is a GUC, and they can
only configure it once pre server.

The postgres-keycloak-oauth-validator is in an even worse situation,
they decided to use a long list of GUC parameters[1]. The main reason
is that they use an introspection endpoint for validation instead of
the JWT, so they need multiple parameters for that. Some of these GUCs
seem redundant to me, but some of them are definitely required.

They also have parameters for the client id and debugging - those are
things we are also considering adding to our validator.

> (I'm only halfway serious with (e) -- I don't really intend to drive
> your thread straight into a wall. But when I read proposals a-c, I get
> the sinking feeling that this *should* be solved in a more radical
> way, if we could only agree on a direction...)

I tried to propose simple things that are relatively easy to
implement, and wouldn't change too much at once, so there's a
realistic change for this making into PG19. I'm not against having a
bigger goal, and continuing making it even better after that.

> A hypothetical PGC_HBA context would seem to fit nicely between
> PGC_SIGHUP and PGC_SU_BACKEND.

How would you configure that since the hba lines don't have IDs?
Should we add a "guc_name" parameter to HBA for this or something like
that? I like this idea, it would be fun to implement and see how it
works, I'm just wondering how users could use it.

[1]: https://github.com/cloudnative-pg/postgres-keycloak-oauth-validator/blob/5fceacf53c3d86fbbe18dab0341311855a89fe6a/src/kc_validator.c#L741

  5. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-17T09:35:51Z

    > Overall, +1 that this limitation is real and worth discussing.I’ll plan to send a patch shortly exploring option (b).

Personally I would go with either (a) or (c), and I was planning to
clean up / improve / share my (c) patch as a second attempt for this
thread, if it didn't receive any replies. I can still do that, so that
we have multiple test implementations. (b) seemed a not as nice design
to me, but maybe you find a better way to implement it than I did.

Also now I really like the idea of the PGC_HBA, if there's a way for
users to configure it without depending on line numbers or other
easy-to-change details.

  6. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-17T18:27:44Z

    On Tue, Dec 16, 2025 at 10:30 PM VASUKI M <vasukianand0119@gmail.com> wrote:
> Overall, +1 that this limitation is real and worth discussing.I’ll plan to send a patch shortly exploring option (b).

Thanks!

> Reg very long HBA lines: totally agree this is a real readability issue,but allowing per-line includes or external file feels like a seperate(and much bigger)topic,probably best tackled independently.

I forgot to mention in my reply to Zsolt, but we've supported inline
inclusions in HBA for a few releases now. (I just frequently forget
they exist.)

pg_hba.conf:

    hostssl  all  all  0.0.0.0/0  oauth  @oauth-settings.conf

oauth-settings.conf:

    issuer=https://oauth.example.org/v2
    scope="openid email let-me-into-pg"
    validator=example_org
    map=examplemap

And for smaller annoyances, you can wrap lines with backslash continuation.

I haven't used these new features much, since I forget they exist, so
if there are usability problems in practice please say something so we
can fix it.

--Jacob

  7. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-17T19:01:20Z

    On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Instead we decided to let everyone configure which claim they want to
> use for user mapping. But because of that, this is a GUC, and they can
> only configure it once pre server.

We're getting closer; I agree that this needs to be more flexible than
it is, and I'm on board with a change, but I'm still missing the
"killer app". What's the case where a user has multiple HBA lines that
all want to use unrelated claims for authentication to one Postgres
cluster? Is this multi-tenancy, or...?

> I tried to propose simple things that are relatively easy to
> implement, and wouldn't change too much at once, so there's a
> realistic change for this making into PG19. I'm not against having a
> bigger goal, and continuing making it even better after that.

Absolutely -- that's a tried and true strategy. No objections to that.

But I also didn't want to stay silent on my longer-term goals here.
That way (hopefully), no one's surprised to find I'm lukewarm on
patches that are extremely OAuth-specific, or that don't give us a way
to improve/evolve later. The additional flexibility of OAuth should
ideally be mirrored in other auth methods when possible.

> > A hypothetical PGC_HBA context would seem to fit nicely between
> > PGC_SIGHUP and PGC_SU_BACKEND.
>
> How would you configure that since the hba lines don't have IDs?
> Should we add a "guc_name" parameter to HBA for this or something like
> that? I like this idea, it would be fun to implement and see how it
> works, I'm just wondering how users could use it.

I hadn't thought it through very far; my initial impression was that
we'd need some sort of additional syntax. But I keep coming back to
httpd-style configs and then I choose something else from my TODO list
to focus on. :) See also the old conversation regarding LDAP hba/ident
[1].

On Wed, Dec 17, 2025 at 1:36 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> Personally I would go with either (a) or (c), and I was planning to
> clean up / improve / share my (c) patch as a second attempt for this
> thread, if it didn't receive any replies. I can still do that, so that
> we have multiple test implementations.

The more the merrier!

Thanks,
--Jacob

[1] https://postgr.es/m/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw%40mail.gmail.com

  8. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-17T23:52:57Z

    > I forgot to mention in my reply to Zsolt, but we've supported inline
> inclusions in HBA for a few releases now. (I just frequently forget
> they exist.)

Thanks, I didn't know about that feature, that solves half of my problem.

> What's the case where a user has multiple HBA lines that
> all want to use unrelated claims for authentication to one Postgres
> cluster? Is this multi-tenancy, or...?

For configuring the authn matching yes, the use case is multitenancy.

But for some other variables that we didn't implement yet, this could
be useful even without multitenancy.

One thing I mentioned in the previous email is the client id
validation. A practical use case of that would be restricting which
oauth clients can login to which database. I can't use a SUSET
variable with a check restricting it to ALTER DATABASE, because
database level variables are not yet available during the oauth
validator callback. I could use a login event trigger, but that seems
like a bad hack to me.

  9. Re: Custom oauth validator options

    VASUKI M <vasukianand0119@gmail.com> — 2025-12-18T05:14:05Z

    On Thu, Dec 18, 2025 at 12:31 AM Jacob Champion <
jacob.champion@enterprisedb.com> wrote:

> On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi <zsolt.parragi@percona.com>
> wrote:
> > Instead we decided to let everyone configure which claim they want to
> > use for user mapping. But because of that, this is a GUC, and they can
> > only configure it once pre server.
>
> We're getting closer; I agree that this needs to be more flexible than
> it is, and I'm on board with a change, but I'm still missing the
> "killer app". What's the case where a user has multiple HBA lines that
> all want to use unrelated claims for authentication to one Postgres
> cluster? Is this multi-tenancy, or...?
>
> Beyond multitenancy,per -HBA OAuth  cases where options are needed for
safe provider migration[blue/green],per-database security policies,mixed
Human/machine authentication[JWT/Introspection] and incident-response
scenarios -all global GUCs are too coarse.

See also the old conversation regarding LDAP hba/ident
> [1]
>
> [1]
> https://postgr.es/m/CAOuzzgpFpuroNRabEvB9kST_TSyS2jFicBNoXvW7G2pZFixyBw%40mail.gmail.com


 Thanks, Will go through it.

Regards,

Vasuki M
CDAC,Chennai.

  10. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-18T09:08:10Z

    > Personally I would go with either (a) or (c), and I was planning to
> clean up / improve / share my (c) patch as a second attempt for this
> thread, if it didn't receive any replies. I can still do that, so that
> we have multiple test implementations.

I attached the patch. It modifies one of the existing oauth_validator
tests to showcase how it works, but in theory it isn't dependent on
oauth. It however requires shared_preload_libraries (that is common
for all options), maybe oauth_validator_libraries could imply that?

  11. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-18T17:27:22Z

    On Thu, Dec 18, 2025 at 1:08 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> It however requires shared_preload_libraries (that is common
> for all options), maybe oauth_validator_libraries could imply that?

Haven't looked at the patch yet, but I think most people probably want
to use session_preload_libraries, not shared_preload_libraries, so
that a security update to their validator doesn't require a restart of
the cluster.

If a particular validator implementation requires shared preload, so
be it; but I don't think we want to force it. Might be more reason to
look into the GUC system?

--Jacob

  12. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-18T18:28:11Z

    > Might be more reason to look into the GUC system?

I am already thinking about that, I have some ideas for a proof of
concept, but no working prototype yet. But without requiring
shared_preload_libraries, we can't do early error reporting during
postmaster startup about custom parameters. Is that okay? GUCs already
work this way, and this could be a bit safer (reporting unknown
parameters/refusing to proceed during login, when we can completely
parse all parameters), but it would be different compared to how
pg_hba is handled currently.

  13. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2025-12-18T18:43:01Z

    On Thu, Dec 18, 2025 at 10:28 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> But without requiring
> shared_preload_libraries, we can't do early error reporting during
> postmaster startup about custom parameters. Is that okay?

I think I need to do more staring at the intersection of GUC
registration and session_preload_libraries, because my memory of the
order of operations was faulty. I won't be able to do that before the
holidays, most likely.

--Jacob

  14. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-18T20:29:20Z

    > I think I need to do more staring at the intersection of GUC
> registration and session_preload_libraries, because my memory of the
> order of operations was faulty. I won't be able to do that before the
> holidays, most likely.

Maybe I'm missing something, but why do we need
session_preload_libraries? oauth_validator_libraries is processed
earlier, it can already define sighup GUCs, it should also work with a
new level around that. I assume that if postgres gets another
authentication plugin point later, it will be executed around the same
place, during authentication, so that also shouldn't be an issue.

The question is if non-validator libraries should be able to define
PGC_HBA variables. If yes, then either

* we don't validate that all HBA variables are valid - if somebody
made a typo, we can't detect it
* we add a sighup guc with a manual whitelist
* require shared preload libraries or oauth_validator_libraries,
because those are loaded before or during authentication
* require session_preload_libraries. We proceed with authentication
even with unresolved HBA variables, but abort the connection if there
are still unknown parameters after loading session preload.

  15. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-05T18:53:06Z

    On Thu, Dec 18, 2025 at 12:29 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
>
> > I think I need to do more staring at the intersection of GUC
> > registration and session_preload_libraries, because my memory of the
> > order of operations was faulty. I won't be able to do that before the
> > holidays, most likely.
>
> Maybe I'm missing something, but why do we need
> session_preload_libraries?

Well, how do you want "global" GUCs registered by the validator to
behave when OAuth isn't used for the connection?

> The question is if non-validator libraries should be able to define
> PGC_HBA variables.

I think we should try for that, yeah. Otherwise I suspect considerable
pushback on the idea of modifying the GucContext enum for something
that can only be used by OAuth.

> * require session_preload_libraries. We proceed with authentication
> even with unresolved HBA variables, but abort the connection if there
> are still unknown parameters after loading session preload.

Of those choices, this _seems_ nicest. It'd be good to get a feel for
how it behaves in practice though.

Thanks,
--Jacob

  16. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-14T18:20:05Z

    > Well, how do you want "global" GUCs registered by the validator to
> behave when OAuth isn't used for the connection?

My assumption was that with session_preload we only validate the line
used for the current login, not all the lines. This way we don't have
to always include all validator/hba plugins in session_preload, for
every login.

This is what I implemented for now, but if you think it would be
better to validate every line, I can adjust that.

> Of those choices, this _seems_ nicest. It'd be good to get a feel for
> how it behaves in practice though.

See the attached v2, with the above comment.

Other than the above question (validate everything vs the current
line), I'm also not entirely sure if we do need PGC_HBA. It could also
work with PGC_SIGHUP + the new PGC_S_HBA value in GucSources.

  17. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-16T01:54:00Z

    On Wed, Jan 14, 2026 at 10:20 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
>
> > Well, how do you want "global" GUCs registered by the validator to
> > behave when OAuth isn't used for the connection?
>
> My assumption was that with session_preload we only validate the line
> used for the current login, not all the lines. This way we don't have
> to always include all validator/hba plugins in session_preload, for
> every login.
>
> This is what I implemented for now, but if you think it would be
> better to validate every line, I can adjust that.

Let me think about that a bit, and look over your v2 approach; my
kneejerk reaction was that this is a dangerous situation to be in. I
want to know that my HBA is invalid when I reload, not later on down
the line.

But my understanding of GUCs from session_preload_libraries also had
some wishful thinking behind it. I believed that the situation today
was stricter than it actually is:

    $ tail -2 data/postgresql.conf
    session_preload_libraries = auto_explain
    auto_explain.blahblahblah = yes

    $ psql postgres
    WARNING:  invalid configuration parameter name
"auto_explain.blahblahblah", removing it
    DETAIL:  "auto_explain" is now a reserved prefix.
    psql (18.0)
    Type "help" for help.

And it makes sense that the postmaster is not going to somehow unload
and reload those libraries during SIGHUP, just to check GUC settings.
Hrmmm...

(If we did go in this direction, I think we might want to be
punishingly strict for the first iteration of the feature. PGC_HBA
providers should prefix their settings to avoid confusion and/or
future collisions anyway, so if we don't know what the GUC is, and its
prefix doesn't match either a validator name -- which is DBA-blessed
-- or a valid session_preload_libraries item, I'm not sure we should
even wait to complain.)

> > Of those choices, this _seems_ nicest. It'd be good to get a feel for
> > how it behaves in practice though.
>
> See the attached v2, with the above comment.

Thank you!

> Other than the above question (validate everything vs the current
> line), I'm also not entirely sure if we do need PGC_HBA. It could also
> work with PGC_SIGHUP + the new PGC_S_HBA value in GucSources.

I might be misunderstanding, but wouldn't that imply that DBAs could
now put every existing SIGHUP setting into HBA? That doesn't seem
good. My hope was that some existing SIGHUP variables could be
downgraded to HBA variables (say, gss_accept_delegation or
authentication_timeout -- though there might be a chicken-and-egg
issue for the latter?), but that's going to be a short list.

--Jacob

  18. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-16T08:30:50Z

    > Let me think about that a bit, and look over your v2 approach; my
> kneejerk reaction was that this is a dangerous situation to be in. I
> want to know that my HBA is invalid when I reload, not later on down
> the line.

Yes, I see that concern, but that's a bit trickier. To do that
properly we have to validate the variables, including their values,
not just their names. If we only validate the names, that doesn't
guarantee anything.

> And it makes sense that the postmaster is not going to somehow unload
> and reload those libraries during SIGHUP, just to check GUC settings.
> Hrmmm...

Would it be a good idea for it to dlopen/dlclose libraries? The
requirements of dlclose are not that strict, I'm not sure if it could
cause any issues. Opening a quick background process to verify it
seems safer, but even then, it could only verify the libraries
mentioned directly in the configuration.

I could write the code that does this for pg_hba on startup/reload,
but the tricky part is that we have to document that properly, to make
sure that the extensions also expects and handles the situation
correctly (that we try to validate gucs for all hba lines). Or start
one background process per hba line...

> I might be misunderstanding, but wouldn't that imply that DBAs could
> now put every existing SIGHUP setting into HBA? That doesn't seem
> good.

Yes, that would mean that. I'm not saying that would be
better/semantically correct, but technically it could also work,
that's why I mentioned it. The main use of PGC_HBA in this patch is to
add additional error reporting / separate what can be placed into
pg_hba. I could argue both for this approach and the opposite where we
allow other variables in pg_hba.

  19. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-16T16:39:04Z

    On Fri, Jan 16, 2026 at 12:31 AM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> Yes, I see that concern, but that's a bit trickier. To do that
> properly we have to validate the variables, including their values,
> not just their names. If we only validate the names, that doesn't
> guarantee anything.

Right. This goes back to your question upthread as to why I brought
session_preload_libraries into all this -- I thought
session_preload_libraries already had handling for this, but it
doesn't.

> Would it be a good idea for it to dlopen/dlclose libraries?

No, unfortunately.

> The
> requirements of dlclose are not that strict, I'm not sure if it could
> cause any issues.

Last I knew (which was a while back), unloading a shared library tree
is fraught with peril, especially when you add dependency diamonds and
static initializers. I seem to remember that Windows, C++, and OpenSSL
all have particular areas of pain. My guess is that people are going
to make mistakes, leave dangling references around, and then either
crash the postmaster or (worse) copy a crashable address space into
every new backend.

And that's before you get into hooks and GUCs and etc. We used to have
a _PG_fini() callback for modules. It was disabled a long time ago
[1], then recently entirely removed from the codebase.

> > I might be misunderstanding, but wouldn't that imply that DBAs could
> > now put every existing SIGHUP setting into HBA? That doesn't seem
> > good.
>
> Yes, that would mean that. I'm not saying that would be
> better/semantically correct, but technically it could also work,
> that's why I mentioned it.

Okay, but that wouldn't be a committable change.

> The main use of PGC_HBA in this patch is to
> add additional error reporting / separate what can be placed into
> pg_hba. I could argue both for this approach and the opposite where we
> allow other variables in pg_hba.

Not sure what you mean by this (maybe once I can really test the
patch, I'll see?), but the reason I suggested placing PGC_HBA right
after PGC_SIGHUP is this: any SU_BACKEND or below variable seems
logically appropriate to set per HBA line, if the DBA wants (they're
all per-session), and anything SIGHUP or above is inappropriate/unsafe
(they're per-cluster). Does your patch disable the former?

[checks] Ah, it does prohibit those. Why?

--Jacob

[1] https://postgr.es/c/602a9ef5a7c60151e10293ae3c4bb3fbb0132d03

  20. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-16T17:13:52Z

    > Last I knew (which was a while back),

Yes, I didn't want to say anything for sure, but I have similar
memories on Windows a while ago. I don't know anything for sure about
today, and especially on Linux, but delegating things to another
process seems to be a safer approach to me.

> [checks] Ah, it does prohibit those. Why?

Mainly because I couldn't decide where it should fit if the variable
is set at multiple places (or if we need multiple sources like
PGC_S_DATABASE_USER).

* A hba line can be completely generic, which should be above DATABASE
(ALTER DATABASE setting should override HBA setting, as it is more
specific)
* Or very specific about one user in one database using a specific
authentication method, which should be below DATABASE_USER as it is
more specific. (hba setting should override ALTER USER ... IN DATABASE
setting)

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.

  21. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-16T17:52:11Z

    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

  22. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-19T20:30:04Z

    > 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?

I would say yes, because in the ALTER ROLE case, it's clear that a
role specific setting is more specific. But I also understand this
reasoning, I'll update the patch to follow this approach.

> Right. This goes back to your question upthread as to why I brought
> session_preload_libraries into all this -- I thought
> session_preload_libraries already had handling for this, but it
> doesn't.

I looked into the previous idea I mentioned, about using child
processes for the purpose, and got that working.

* to prevent pg_hba reloads if something is invalid in it
* possibly to print out a warning (or error/fatal) during postmaster
startup along/instead of the connection warning
* possibly to do the same during sighup

The "instead of connection warning" (removing the placeholders from
postmaster) part is a bit complex or limited, as the postmaster can't
use dsm, and there can be any number of variables.

This is again a bit of a different topic, but I could make that a
proper patch from this prototype.

The important part for this thread is that if you would prefer a
version which completely verifies the pg_hba configuration before
accepting it, it's not that difficult to implement, or at least it's
not as complex as I originally imagined it. But even that won't
guarantee that the configuration always remains valid, because session
preload libraries can change without a server restart/reload... but
that's a rare corner case, and it could be a useful check most of the
time.

  23. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-20T18:02:16Z

    On Mon, Jan 19, 2026 at 12:30 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> This is again a bit of a different topic, but I could make that a
> proper patch from this prototype.

Let's separate the "verify session-preloaded GUCs" question from this
feature request, yeah.

> The important part for this thread is that if you would prefer a
> version which completely verifies the pg_hba configuration before
> accepting it, it's not that difficult to implement, or at least it's
> not as complex as I originally imagined it. But even that won't
> guarantee that the configuration always remains valid, because session
> preload libraries can change without a server restart/reload... but
> that's a rare corner case, and it could be a useful check most of the
> time.

Right. I've been thinking about strategy here, and I'm not sure I've
solidified my thoughts yet, but I don't want to make you wait for
that. So here goes:

The inability to verify the HBA settings, without actively loading the
extension, is a drawback whether we introduce a PGC_HBA or not. I feel
pretty strongly that we can't require shared_preload_libraries for
this use case. And given the choice between "you cannot modify per-HBA
settings at all" and "we can't tell you until you test them whether
they're valid or not", most people would probably prefer the latter
limitation. Especially since the *values* for many existing HBA
parameters cannot truly be "validated" without testing anyway;
consider ldapserver etc.

Since session_preload_libraries already can't do this, I don't feel
too bad about us not doing it for a first version of the feature, but
this limitation is likely to remain for a long time. Unless you think
that there's a technical solution where the benefit easily outweighs
the maintenance cost. And my guess is that this conversation is about
to collide at high speed with the Postgres-threading work that's in
progress.

I like the idea of a PGC_HBA. I think it makes a lot of sense to be
able set other GUC overrides here -- authentication_timeout,
log_connections, pre/post_auth_delay. It seems architectually sound
and generically useful.

I'm worried that it's about to make a different decision from the
decision that is being made for the pg_hosts.conf file for SNI. So
this is not going to feel cohesive at first, and that's only "okay" if
it becomes cohesive very quickly, which requires a larger audience.

I'm also worried about namespace collisions between GUC and HBA. If we
scope it to OAuth then that becomes easier (e.g. just prepend
`validator.` or something to the setting name in HBA and then it's
obvious what's going on). But if someone decides in PG20 that
pam_use_hostname is a good GUC name for something, we're in trouble,
because the existing HBA options do not plug into the GUC system.

That's a lot of risk. High revert potential without multiple
maintainers saying "yes", IMO, and if that happens we will have no
improvement here for PG19.

So,
1) how close to the sun do you feel like flying today?
2) do you agree with the above?
3) can your option (b) or (c) make enough use of existing GUC
infrastructure, so that a future PGC_HBA could easily subsume an
OAuth-specific solution, if people want to continue down that path in
a less OAuth-centric thread?

--Jacob

  24. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-20T20:31:11Z

    > I'm not sure I've solidified my thoughts yet

I can wait if you would prefer more time to think about the problem, I
can work on other things in the meantime and we still have several
months before the code freeze. I mainly wanted to share my findings
with this experiment, and that was also a fun side project to try.

> 2) do you agree with the above?

Yes. I'm fine with not verifying everything perfectly (or as close as
perfectly as we can). I like my currently submitted version better
than the child process verification version, but I wanted to see if it
is doable or not, and to see what challenges there are.

> But if someone decides in PG20 that
> pam_use_hostname is a good GUC name for something, we're in trouble,
> because the existing HBA options do not plug into the GUC system.

We could make them reserved names? Or maybe even accessible as GUC
variables, even if we leave the current parsing/validation logic as
is. Making them proper GUC variables seemed like a clear follow up
patch to me, even if not for pg19.

> I'm worried that it's about to make a different decision from the
> decision that is being made for the pg_hosts.conf file for SNI.

I probably should read that thread in more detail, but I assume that
your worry is about pg_hosts being a hardcoded configuration instead
of using a similarly customizable GUC context? Shouldn't that be
fixable in the future similarly?

> 3) can your option (b) or (c) make enough use of existing GUC
> infrastructure, so that a future PGC_HBA could easily subsume an
> OAuth-specific solution, if people want to continue down that path in
> a less OAuth-centric thread?

I'm not sure about reusing existing GUC infrastructure, but  I could
make it look similar from the users perspective for example by adding
a function DefineCustomValidatorStringVariable that has a similar
interface to DefineCustomStringVariable, and in the future, this
function could simply forward to DefineCustomStringVariable.

That would limit the variable to be only definable in pg_hba, not
postgresql.conf, but otherwise should work similarly for
validators/users.

I think this would be a larger patch than the real PGC_GUC, but it
would be limited to the pg_hba parser.

> 1) how close to the sun do you feel like flying today?

Now that I have tried the PGC_HBA approach, I like how that works and
integrates with everything, this is a much better solution than my
original ideas.

On the other hand, it would be great to get something working in PG19.
By that time more libraries/tools should actually start to support
oidc, and we will see more use of the feature, and the way we
configure these parameters is important for the validators.

  25. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-24T00:04:39Z

    On Tue, Jan 20, 2026 at 12:31 PM Zsolt Parragi
<zsolt.parragi@percona.com> wrote:
> > But if someone decides in PG20 that
> > pam_use_hostname is a good GUC name for something, we're in trouble,
> > because the existing HBA options do not plug into the GUC system.
>
> We could make them reserved names?

I'm wondering if we should maybe do the opposite, and namespace the
GUCs instead? The vast majority of settings in an HBA are not going to
be GUCs, they're going to be method-specific parameters. So maybe it's
okay to have to do more typing to do the uncommon thing, and reference
them like `guc.log_connections` or something.

> Or maybe even accessible as GUC
> variables, even if we leave the current parsing/validation logic as
> is. Making them proper GUC variables seemed like a clear follow up
> patch to me, even if not for pg19.

Hmm... we may want to discuss my (e) option derailment more seriously,
if we're planning to go in that direction (and if other people like
that direction).

> > I'm worried that it's about to make a different decision from the
> > decision that is being made for the pg_hosts.conf file for SNI.
>
> I probably should read that thread in more detail, but I assume that
> your worry is about pg_hosts being a hardcoded configuration instead
> of using a similarly customizable GUC context? Shouldn't that be
> fixable in the future similarly?

"Fixable" in what sense? pg_hosts.conf is currently similar to
pg_ident.conf in that it has no place for key=value pairs, and if you
add them after as an optional "column" for compatibility, you still
have to write something for all of those columns that you were trying
to replace with the GUC settings.

> > 3) can your option (b) or (c) make enough use of existing GUC
> > infrastructure, so that a future PGC_HBA could easily subsume an
> > OAuth-specific solution, if people want to continue down that path in
> > a less OAuth-centric thread?
>
> I'm not sure about reusing existing GUC infrastructure, but  I could
> make it look similar from the users perspective for example by adding
> a function DefineCustomValidatorStringVariable that has a similar
> interface to DefineCustomStringVariable, and in the future, this
> function could simply forward to DefineCustomStringVariable.

Might work, yeah.

--Jacob

  26. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-26T09:51:02Z

    > Hmm... we may want to discuss my (e) option derailment more seriously,
> if we're planning to go in that direction (and if other people like
> that direction).

I know you wrote that you are only half serious about it, and I
definitely do not want to go in the "lets completely refactor pg_hba
in this patch" direction, but keeping that idea in mind seems like a
good idea to me. The choosing authentication method part would already
be useful with OAuth, and now Joel also started a thread about fido2,
which also brings the question of MFA. Pluggable generic
authentication would also require generic GUC variables at this level.

Scoping validators to a specific prefix fixes the collision issue, but
it also goes in a different direction. Because of this I like the
other alternative idea (DefineCustomValidatorStringVariable) better,
if we want to go with a smaller change for this, but I still have to
implement that and see how it behaves in practice.

> "Fixable" in what sense? pg_hosts.conf is currently similar to
> pg_ident.conf in that it has no place for key=value pairs, and if you
> add them after as an optional "column" for compatibility, you still
> have to write something for all of those columns that you were trying
> to replace with the GUC settings.


pg_hba has the same issue, even if it has custom key=value data
already. What I meant is similarly how we could turn currently hard
coded pg_hba settings into GUC variables, the same is doable with
pg_hosts, either at a separate level or integrating it into the HBA
context. And later either both should get a new line style and
deprecate the old one, or maybe these settings should be configured
completely differently.

  27. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-01-27T17:40:32Z

    On Mon, Jan 26, 2026 at 1:51 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> The choosing authentication method part would already
> be useful with OAuth, and now Joel also started a thread about fido2,
> which also brings the question of MFA.

Or just the ability to offer a choice between two authentication
methods for a single user, yeah.

> pg_hba has the same issue, even if it has custom key=value data
> already. What I meant is similarly how we could turn currently hard
> coded pg_hba settings into GUC variables, the same is doable with
> pg_hosts, either at a separate level or integrating it into the HBA
> context. And later either both should get a new line style and
> deprecate the old one, or maybe these settings should be configured
> completely differently.

Sure; at this point I think we're violently agreeing. If we suspect
the configuration UX needs to be refactored, that's not going to be a
decision made unilaterally in this thread, which is why I said I was
worried about the scope creep.

--Jacob

  28. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-28T16:04:49Z

    I implemented a DefineCustomValidatorStringVariable PoC - I don't like
it that much. It adds too much boilerplate code for a very specific
feature. If you say we should go with a more limited approach, I think
my earlier simple version is better, because it is simple. I'll also
try to think about other approaches.

And also let me go back to my concern that

> Scoping validators to a specific prefix fixes the collision issue, but
> it also goes in a different direction.

I wrote this because of the simple "guc.some_name" example, as the
fixed guc prefix - and previously I also looked into
MarkGUCPrefixReserved, and I realized that there's no easy way to use
that for enforcing prefixes for a library.

And then I realized that maybe that needs an improvement, the behavior
of MarkGUCPrefixReserved and DefineCustom*Variable seems like a legacy
thing and not something that was intentionally designed that way.

What do you think about the following patches?

0001: defines a new guc, guc_prefix_enforcement that potentially
changes the behavior of prefix reservation. It has a few modes, based
on which missing prefix reservations or variables defined outside the
reserved prefix result in warnings or errors during library load time.
This is unrelated to pgc_hba, and applies to all custom variables.

0002: the same patch as before, with your comment (su_backend,
backend, suset, user can be set in pg_hba) addressed, and also always
enforces proper prefix reservation for pg_hba variables using 0001.

* We don't have to worry about collisions, because prefixes are always
enforced in pg_hba, so people can't "redefine" the fixed key/value
pairs or columns
* It also introduces the idea of enforcing guc prefixes for
extensions. In theory this setting should start with a relaxed default
(I would say warning mode), and changed to strict in a later major
version, enforcing proper guc rules by default. That way, third party
extensions won't be able to define gucs like pam_use_hostname.

I realize that

1. This is also scope creep
2. 0001 probably should be a separate thread/discussion

But I first wanted to ask your opinion about the idea / what do you
think about the interaction of the two patches.

  29. Re: Custom oauth validator options

    Álvaro Herrera <alvherre@kurilemu.de> — 2026-01-28T16:23:39Z

    On 2026-Jan-28, Zsolt Parragi wrote:

> 0001: defines a new guc, guc_prefix_enforcement that potentially
> changes the behavior of prefix reservation. It has a few modes, based
> on which missing prefix reservations or variables defined outside the
> reserved prefix result in warnings or errors during library load time.
> This is unrelated to pgc_hba, and applies to all custom variables.

I didn't actually read this patch, but I wonder if this is something we
should attempt in the context of the larger refactoring done by the
patch series here,
https://postgr.es/m/2438819.yKrmzQ4Hd0@thinkpad-pgpro
I'm afraid it's likely to be very outdated at the moment, I think it'll
need a difficult rebase, but I invite you to have a look at what it
offered when it was last posted, and see if it would help write what
you're trying to achieve here.

Thanks

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"I'm always right, but sometimes I'm more right than other times."
                                                  (Linus Torvalds)
https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/

  30. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-28T19:21:13Z

    > but I wonder if this is something we
> should attempt in the context of the larger refactoring done by the
> patch series here,

That patch series is interesting but it is about SQL (table, index,
operator) options, while this is about guc variable validation and
extension. These seem unrelated to me.

  31. Re: Custom oauth validator options

    Nikolay Shaplov <dhyan@nataraj.su> — 2026-01-29T11:58:52Z

    On 28.01.2026 22:21, Zsolt Parragi wrote:
>> but I wonder if this is something we
>> should attempt in the context of the larger refactoring done by the
>> patch series here,
> That patch series is interesting but it is about SQL (table, index,
> operator) options, while this is about guc variable validation and
> extension. These seem unrelated to me.

This patch suggests context independent API for managing extension 
defined sets of options. It is used for
relation options and similar options, but cat be also used for any 
options sets, may be with small modifications.

GUC options are almost same options as relation options. That is why, I 
guess, Alvaro suggested you to look at this patch.

And I agree with him. Please have a look at 
src/backend/access/common/options.c in that patch. I almost sure this 
code can be reused for GUC options too.

Whole https://commitfest.postgresql.org/patch/4688/ is a bit outdated, 
and need rebase, but options.c from it is as good as it was before.

And we've just recently committed a small fix that have been blocking 
4688's patch rebase. I have plans to rebase it in not so distant future.

It you find it useful for your tasks and even would like to join to 
review (at least for options.c part) I would do it with higher priority.
(but it is still my weekend-days project, so it can't be extremely fast)

  32. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-01-29T13:00:57Z

    > This patch suggests context independent API for managing extension
> defined sets of options. It is used for
> relation options and similar options, but cat be also used for any
> options sets, may be with small modifications.
>
> GUC options are almost same options as relation options. That is why, I
> guess, Alvaro suggested you to look at this patch.

Yes, but wouldn't that still require a generic refactoring of GUCs?
I'm not saying that would be a bad thing, but that's a big task in
itself.

But if I think about it in the general context of this thread (adding
extension options to pg_hba, ignoring the part that I tried to
implement it with GUCs in the current patch), that can be related.

Thanks for the clarification, I'll look into it in more detail.

  33. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-02-04T11:42:12Z

    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.

  34. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-20T17:46:46Z

    Hi all,

First, an apology for the state of this thread -- I thought I had
already responded to the prior message last month. Turns out, I had
not... Instead, I'm dropping a surprise alternative patchset on top of
a thread that I let go cold, which is rude, and I'm sorry.

Here are my overall thoughts on the approaches shared so far. And
thank you, Zsolt, for doing so much legwork here; that effort was not
wasted at all.

1) A GUC-centric solution -- option (d) -- is the Ideal Solution here,
IMO. We shouldn't have to reinvent the wheel.

2) A GUC-centric solution is not going to land for 19, and I'd be
surprised if it landed for 20, given the coalition that I'll need to
build to say either "yes" or "no". There are too many questions about
session_preload_libraries and prefixing and etc., and I'm honestly not
a fan of the guc_prefix_enforcement approach.

3) I'm not convinced yet that GUCs and relation options are similar
enough to share a framework. (This is not a rejection of the reloption
refactoring work, just a statement that I don't want to rely on it to
solve this problem.)

4) I really don't like the hba_parse_option_hook. I prefer APIs over
hooks as a general architectural point, and more practically, I don't
want to hand control to extensions during HBA parsing. I don't think
they're going to coordinate with each other well, and I think they're
likely to couple against internals in ways we don't want to support
(which is my general problem with hooks).

= Option (b) =

I don't want this problem to go unfixed for 2+ years, so I think it
would be best to reinvent a very small wheel that doesn't take up a
lot of maintenance effort once it's in, and then simply replace it
with the Ideal Solution eventually. This is my take on option (b),
which is what Vasuki M advocated for upthread. It's just a
setter/getter API for string keys and values:

  static const char* opts[] = { "my_parameter" };

  void startup_cb(ValidatorModuleState *state)
  {
      RegisterOAuthHBAOptions(state, lengthof(opts), opts);
  }

  bool validate_cb(const ValidatorModuleState *state, ...)
  {
      const char *param;
      if ((param = GetOAuthHBAOption(state, "my_parameter")) != NULL)
          do_something_with(param);
      ...
  }

And then in your HBA:

  host all all ::1/128 oauth validator.my_parameter=foo ...

The core implementation is conceptually simple. Most of the lines in
the patch are guardrails, to reduce the probability of regret over
this temporary solution:
- Parameter names aren't freeform; they're restricted to
almost-alphanumeric identifiers. (We've wanted to steal symbols for
HBA features in the past.)
- Name syntax is checked on reload, but cross-referencing the
registered list must be deferred to connection time. That's unusual
for users, so the WARNING that gets printed in this case is extremely
verbose; that way hopefully no one will be confused about what is
happening.
- The compiler won't let you register names during validate_cb, and we
won't let you retrieve options during startup_cb, so we retain control
over the internal order of operations. (This is discussed more deeply
in the patch.)

I was worried that we'd need a third API call to report option parsing
failures from the validator. Instead of doing that, I've made it
easier to link an authentication failure to a validator internal error
that caused it, in v3-0001, which serendipitously fixes a separate
sharp edge [1]. I feel good about that patch even if -0002 doesn't
make it.

v3-0002 still lacks user documentation, which I need to write a lot of
-- but if everyone dislikes this approach then I'd rather not spend
the time there.

= WDYT? =

I realize this puts you all in a difficult position; the effect is
kind of "take it or leave it", which again was not my intent. I
considered letting this lapse for 19 instead. But since I believe the
ideal solution is one we can't have for a while, and there's good
research and discussion of alternatives in this thread, waiting may
not produce a more committable short-term solution in the end.

Let me know if any of you disagree, though -- especially if you think
the status quo is preferable! -- and I can shelve -0002 for now. (I'll
continue with -0001 at [1] either way.)

Thanks,
--Jacob

[1] https://postgr.es/m/202601241015.y5uvxd7oxnfs%40alvherre.pgsql

  35. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-03-23T21:45:38Z

    > I considered letting this lapse for 19 instead

That was also my conclusion. After the discussion in the SNI thread I
started working on a PoC for a more modern syntax for hba/ident/hosts,
hoping that a generic extensibility/guc patch could be based on that.
I also didn't want to start a thread about this before the feature
freeze, so I'm still waiting/prototyping for a few weeks.

I'm also not against adding an oauth-only feature for 19, that was my
original intention before getting completely distracted by the guc
direction :)

+ else if (strncmp(name, "validator.", strlen("validator.")) == 0)
+ {
+ const char *key = name + strlen("validator.");

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?

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)


+ REQUIRE_AUTH_OPTION(uaOAuth, name, "oauth");

Shouldn't this check go before the name validation?

  36. Re: Custom oauth validator options

    Daniel Gustafsson <daniel@yesql.se> — 2026-03-24T12:29:04Z

    > On 23 Mar 2026, at 23:45, Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> 
>> I considered letting this lapse for 19 instead
> 
> That was also my conclusion. After the discussion in the SNI thread I
> started working on a PoC for a more modern syntax for hba/ident/hosts,
> hoping that a generic extensibility/guc patch could be based on that.

FWIW I support this line of investigation and look forward to seeing what it
could look like.

--
Daniel Gustafsson

  37. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-27T23:03:00Z

    On Mon, Mar 23, 2026 at 2:45 PM Zsolt Parragi <zsolt.parragi@percona.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%3DjBR4WrEdJvxjTATKw%40mail.gmail.com

  38. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-27T23:03:16Z

    On Tue, Mar 24, 2026 at 5:29 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> FWIW I support this line of investigation and look forward to seeing what it
> could look like.

+many

--Jacob

  39. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-03-30T21:46:34Z

    > (As one example, `SHOW
> my_validator.setting` isn't going to behave intuitively.)

Right, I didn't think about that scenario, it might be better to keep
this intentionally different.

That won't be the most user friendly option, but it is still
definitely better than not having the ability to configure this.

  40. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-03-30T23:54:18Z

    On Mon, Mar 30, 2026 at 2:46 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
> That won't be the most user friendly option, but it is still
> definitely better than not having the ability to configure this.

Sounds good. Barring other objections, then, I'll plan to move forward
with this approach for PG19.

Thanks!
--Jacob

  41. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-04-02T21:26:54Z

    On Mon, Mar 30, 2026 at 4:54 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Sounds good. Barring other objections, then, I'll plan to move forward
> with this approach for PG19.

v4-0002 (based on top of [1]) addresses Zsolt's feedback and adds the
missing user documentation. I believe this is now a complete patch
proposal; tear it apart. :D

Thanks,
--Jacob

[1] https://postgr.es/m/CAOYmi%2BmvFS7Ukmacb1z%3DxWO7M%2BDPF41GZsJiJ6sh4U1Qm_yWOA%40mail.gmail.com

  42. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-04-03T23:33:15Z

    On Thu, Apr 2, 2026 at 2:26 PM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> v4-0002 (based on top of [1]) addresses Zsolt's feedback and adds the
> missing user documentation. I believe this is now a complete patch
> proposal; tear it apart. :D

v5 is a quick rebase to get rid of v4-0001; no other changes.

--Jacob

  43. Re: Custom oauth validator options

    Zsolt Parragi <zsolt.parragi@percona.com> — 2026-04-06T22:09:27Z

    > 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,
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, this
and the other use could cache the option in a local variable instead
of making duplicate calls, following the pattern of the documentation.

  44. Re: Custom oauth validator options

    Jacob Champion <jacob.champion@enterprisedb.com> — 2026-04-06T22:16:55Z

    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