> 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_lib
On Thu, Dec 18, 2025 at 10:28 AM Zsolt Parragi
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_prel
> 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
On Thu, Dec 18, 2025 at 1:08 AM Zsolt Parragi 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
> 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 th
On Thu, Dec 18, 2025 at 12:31 AM Jacob Champion <
[email protected]> wrote:
> On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi
> 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
>
> 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 wa
On Wed, Dec 17, 2025 at 1:28 AM Zsolt Parragi 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 flexi
On Tue, Dec 16, 2025 at 10:30 PM VASUKI M 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 exter
> 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 repli
> 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
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 feel
Sorry for missing this thread!
On Tue, Dec 2, 2025 at 5:06 AM Zsolt Parragi 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. (Th
13 matches
Mail list logo
