From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Date: | 2022-03-29 23:38:29 |
Message-ID: | 1add3bbf7790214c5a240edbb09b2632e402efb5.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2022-03-26 at 11:36 -0700, Andres Freund wrote:
> > I also note that exposing it as a GUC means we have zero control over
> > who/what can read it. Maybe that's not a problem, but it needs to be
> > thought about before we go down that path.
>
> Yes, I think that's a fair concern.
I like that there's no builtin way, today, for a superuser to modify
the internal value; it strengthens the use as an auditing tool. Moving
this to a PGC_SU_BACKEND GUC seems to weaken that. And it looks like
PGC_INTERNAL is skipped during the serialization, so if we chose that
option, we'd need to write new code anyway?
We'd also need to guess whether the GUC system's serialization of NULL
as an empty string is likely to cause problems for any future auth
methods. My guess is "no", to be honest, but I do like maintaining the
distinction -- it feels safer.
v8 rebases over the recent SSL changes to get the cfbot green again.
Thanks,
--Jacob
Attachment | Content-Type | Size |
---|---|---|
since-v7.diff.txt | text/plain | 873 bytes |
v8-0001-Add-API-to-retrieve-authn_id-from-SQL.patch | text/x-patch | 5.9 KB |
v8-0002-Allow-parallel-workers-to-use-pg_session_authn_id.patch | text/x-patch | 13.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2022-03-29 23:41:41 | Re: Add parameter jit_warn_above_fraction |
Previous Message | Andres Freund | 2022-03-29 23:16:41 | Re: Add parameter jit_warn_above_fraction |