Re: [PATCH] Expose port->authn_id to extensions and triggers - Mailing list pgsql-hackers

On Thu, Feb 24, 2022 at 12:15:40AM +0000, Jacob Champion wrote:
> Stephen pointed out [1] that the authenticated identity that's stored
> in MyProcPort can't be retrieved by extensions or triggers. Attached is
> a patch that provides both a C API and a SQL function for retrieving
> it.
>
> GetAuthenticatedIdentityString() is a mouthful but I wanted to
> differentiate it from the existing GetAuthenticatedUserId(); better
> names welcome. It only exists as an accessor because I wasn't sure if
> extensions outside of contrib were encouraged to rely on the internal
> layout of struct Port. (If they can, then that call can go away
> entirely.)

+char *
+GetAuthenticatedIdentityString(void)
+{
+   if (!MyProcPort || !MyProcPort->authn_id)
+       return NULL;
+
+   return pstrdup(MyProcPort->authn_id);

I don't quite see the additional value that this API brings as
MyProcPort is directly accessible, and contrib modules like
postgres_fdw and sslinfo just use that to find the data of the current
backend.  Cannot a module like pgaudit, through the elog hook, do its
work with what we have already in place?

What's the use case for a given session to be able to report back
only its own authn through SQL?

I could still see a use case for that at a more global level with
beentrys, but it looked like there was not much interest the last time
I dropped this idea.
--
Michael