Re: [PATCH] Expose port->authn_id to extensions and triggers
Drouvot, Bertrand <bdrouvot@amazon.com>
From: "Drouvot, Bertrand" <bdrouvot@amazon.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <jchampion@timescale.com>, Joe Conway <mail@joeconway.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, "sfrost@snowman.net" <sfrost@snowman.net>, "rjuju123@gmail.com" <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "andres@anarazel.de" <andres@anarazel.de>
Date: 2022-08-16T09:02:30Z
Lists: pgsql-hackers
Hi,
On 8/14/22 11:57 AM, Michael Paquier wrote:
> On Fri, Aug 12, 2022 at 03:34:04PM +0200, Drouvot, Bertrand wrote:
>> 3)
>>
>> +SerializeClientConnectionInfo(Size maxsize, char *start_address)
>> +{
>> + /*
>> + * First byte is an indication of whether or not authn_id has been
>> set to
>> + * non-NULL, to differentiate that case from the empty string.
>> + */
>>
>> is authn_id being an empty string possible?
> I don't recall that this can be the case yet, but we cannot discard
> it.
Fair point.
> One thing was itching me about the serialization and
> deserialization logic though: could it be more readable if we used an
> intermediate structure to store the length of the serialized strings?
> We use this approach in other areas, like for the snapshot data in
> snapmgr.c. This would handle the case of an empty and NULL string, by
> storing -1 as length for NULL and >= 0 for the string length if there
> is something set, while making the addition of more fields a
> no-brainer.
I think that's a good idea and I think that would be more readable (as
compare to storing a "hint" in the first byte).
Regards,
--
Bertrand Drouvot
Amazon Web Services: https://aws.amazon.com
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