Re: [PATCH] Expose port->authn_id to extensions and triggers
Jacob Champion <pchampion@vmware.com>
From: Jacob Champion <pchampion@vmware.com>
To: "michael@paquier.xyz" <michael@paquier.xyz>
Cc: "sfrost@snowman.net" <sfrost@snowman.net>, "rjuju123@gmail.com" <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "andres@anarazel.de" <andres@anarazel.de>
Date: 2022-04-06T19:16:43Z
Lists: pgsql-hackers
On Wed, 2022-04-06 at 20:09 +0900, Michael Paquier wrote: > > The current patch already handles NULL with a byte of overhead; is > > there any advantage to using noError? (It might make things messier > > once a second member gets added to the struct.) My concern was directed > > at the GUC proposal. > > FWIW, I am a bit concerned by this approach because it feels > inconsistent with any other conditional fields passed down from the > parallel leader to its workers. And if we need to add more fields to > ParallelProcInfo in the future, it will be cleaner to use different > TOC keys to pass down different fields anyway, no? I assumed that we would follow the existing model of "(de)serialize a whole struct", rather than pulling it apart into many separate keys. If it got too complicated then we could consider introducing a SerializedParallelProcInfo struct like some of the other functions do. Maybe that wouldn't work so well if many of the fields are strings? Is there a significant cost to changing this later, if one approach turns out to be wrong? --Jacob
Commits
-
Remove initialization of MyClientConnectionInfo at backend startup
- 701ac2cb1fa2 16.0 landed
-
Allow parallel workers to retrieve some data from Port
- d951052a9e02 16.0 landed