From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jacob Champion <pchampion(at)vmware(dot)com>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Date: | 2022-02-26 05:39:17 |
Message-ID: | Yhm9BUjrCItExUJu@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> Looks to me like authn_id isn't synchronized to parallel workers right now. So
> the function will return the wrong thing when executed as part of a parallel
> query.
FWIW, I am not completely sure what's the use case for being able to
see the authn of the current session through a trigger. We expose
that when log_connections is enabled, for audit purposes. I can also
get behind something more central so as one can get a full picture of
the authn used by a bunch of session, particularly with complex HBA
policies, but this looks rather limited to me in usability. Perhaps
that's not enough to stand as an objection, though, and the patch is
dead simple.
> I don't think we should add further functions not prefixed with pg_.
Yep.
> Perhaps a few tests for less trivial authn_ids could be worthwhile?
> E.g. certificate DNs.
Yes, src/test/ssl would handle that just fine. Now, this stuff
already looks after authn results with log_connections=on, so that
feels like a duplicate.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-02-26 05:42:33 | Re: Commitfest manager for 2022-03 |
Previous Message | Michael Paquier | 2022-02-26 05:21:01 | Re: Frontend error logging style |