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

From Jacob Champion
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id 2e28b12b450f247d5c0994207030c862263e0297.camel@vmware.com
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> 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.

Right -- I just didn't know if third-party modules were actually able
to rely on the internal layout of struct Port. Is that guaranteed to
remain constant for a major release line? If so, this new API is
superfluous.

> Cannot a module like pgaudit, through the elog hook, do its
> work with what we have already in place?

Given the above, I would hope so. Stephen mentioned that pgaudit only
had access to the logged-in role, and when I proposed a miscadmin.h API
he said that would help. CC'ing him to see what he meant; I don't know
if pgaudit has additional constraints.

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

That's for triggers to be able to grab the current ID for
logging/auditing. Is there a better way to expose this for that use
case?

> 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.

I agree that this would be useful to have in the stats. From my outside
perspective, it seems like it's difficult to get strings of arbitrary
length in there; is that accurate?

Thanks,
--Jacob

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: convert libpq uri-regress tests to tap test
Next
From: Jacob Champion
Date:
Subject: Re: convert libpq uri-regress tests to tap test