Re: [PATCH] Expose port->authn_id to extensions and triggers

On Tue, 2022-04-05 at 15:13 +0900, Michael Paquier wrote:
> On Wed, Mar 30, 2022 at 04:02:09PM +0000, Jacob Champion wrote:
> > Whether that's a problem in the future entirely depends on whether
> > there's some authentication method that considers the empty string a
> > sane and meaningful identity. We might reasonably decide that the
> > answer is "no", but I like being able to make that decision as opposed
> > to delegating it to an existing generic framework.
> 
> My guess on the matter is that an empty authn holds the same meaning
> as NULL because it has no data,

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.

(Postgres rejects empty Subjects when using clientname=DN and I'm not
proposing that we change that; I'm haven't actually checked that
they're RFC-legal. But it's possible that a future auth method could
have a reasonable standard definition for an empty identifier.)

> but I can see your point as well to
> make this distinction.  In order to do that, couldn't you just use
> shm_toc_lookup(noError=true)?  PARALLEL_KEY_SHAREDPORT could be an
> optional entry in the TOC data.

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.

> The name choice is still an issue, as per Andres' point that
> MyProcShared is confusing as it can refer to shared memory.  What we
> want is a structure name for something that's related to MyProc and
> shared across all parallel workers including the leader.  I would
> give up on the "Shared" part, using "Parallel" and "Info" instead.
> Here are some ideas:
> - ProcParallelInfo
> - ProcInfoParallel
> - ParallelProcInfo

I like ParallelProcInfo; it reads nicely. I've used that in v9.

Thanks!
--Jacob