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

From Michael Paquier
Subject Re: [PATCH] Expose port->authn_id to extensions and triggers
Date
Msg-id Yk108M6LazJT7Vsj@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers  (Jacob Champion <pchampion@vmware.com>)
List pgsql-hackers
On Tue, Apr 05, 2022 at 06:23:06PM +0000, Jacob Champion wrote:
> Whether it holds meaning or not depends entirely on the auth method, I
> think. Hypothetical example -- a system could accept client
> certificates with an empty Subject. What identity that Subject
> represents would depend on the organization, but it's distinct from
> NULL/unauthenticated because the certificate is still signed by a CA.

Interesting point.

> 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?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres?
Next
From: Filip Janus
Date:
Subject: Practical Timing Side Channel Attacks on Memory Compression