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 YkveFfb8VAnKUHnM@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 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, 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 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
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Amit Kapila
Date:
Subject: Re: Handle infinite recursion in logical replication setup