Re: [PATCH] Expose port->authn_id to extensions and triggers
От | Julien Rouhaud |
---|---|
Тема | Re: [PATCH] Expose port->authn_id to extensions and triggers |
Дата | |
Msg-id | 20220224171538.jbf2cxzmhiwuinp4@jrouhaud обсуждение исходный текст |
Ответ на | Re: [PATCH] Expose port->authn_id to extensions and triggers (Jacob Champion <pchampion@vmware.com>) |
Ответы |
Re: [PATCH] Expose port->authn_id to extensions and triggers
|
Список | pgsql-hackers |
Hi, On Thu, Feb 24, 2022 at 04:50:59PM +0000, Jacob Champion wrote: > 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. Yes, third-party can rely on Port layout. We don't break ABI between minor release. In some occasions we can add additional fields at the end of a struct, but nothing more. > > 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? Yes, as it's all in shared memory. The only workaround is using something like track_activity_query_size, but it's not great.
В списке pgsql-hackers по дате отправления: