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
signature.asc
Description: PGP signature