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