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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jacob Champion <pchampion(at)vmware(dot)com>
Cc: "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [PATCH] Expose port->authn_id to extensions and triggers
Date: 2022-04-05 06:13:41
Message-ID: YkveFfb8VAnKUHnM@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-04-05 06:15:50 Re: Handle infinite recursion in logical replication setup
Previous Message Masahiko Sawada 2022-04-05 06:05:10 Re: Skipping logical replication transactions on subscriber side