Hi,
Michael Paquier writes:
> [[PGP Signed Part:Undecided]]
> On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
>
> My main worry here is EXEC_BACKEND, where we would just use our own
> implementation of fork(), and it is a bad idea at the end to leave
> that untouched while we co
Michael Paquier writes:
> On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
>> When can we rely on static initialization, and when can't we? Is there a
>> concern that the memory could have been polluted from before the
>> postmaster's fork?
> My main worry here is EXEC_BACKEND, whe
On Tue, Aug 23, 2022 at 10:04:30AM -0700, Jacob Champion wrote:
> On 8/23/22 01:53, Drouvot, Bertrand wrote:
>> @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)
>>
>> MyProcPid = getpid();
>>
>> MySta
On 8/23/22 01:53, Drouvot, Bertrand wrote:
> That sounds all good to me, except a typo for the author in the commit
> message: s/Jocob/Jacob/
Thanks, I missed that on my readthrough! :D
Patch looks good to me, too, with one question:
> @@ -2688,6 +2689,7 @@ InitProcessGlobals(void)
On Mon, Aug 22, 2022 at 08:10:10AM -0700, Jacob Champion wrote:
> otherwise I'll sit tight.
So am I. I have done an extra round of checks around the
serialization/deserialization logic where I put some elog()'s to look
at the output passed down with some workers and a couple of auth
methods, and
On Mon, Aug 22, 2022 at 4:32 AM Michael Paquier wrote:
> By the way, I have looked at the patch, tweaked a couple of things
> with comments and the style, but overval that's fine. First, I have
> intended to apply this stuff today but I have lacked the time to do
> so. I should be able to get th
On Wed, Aug 17, 2022 at 09:53:45AM +0200, Drouvot, Bertrand wrote:
> Thanks for the new version!
>
> + /* Copy authn_id into the space after the struct. */
> + if (serialized.authn_id_len >= 0)
>
> Maybe remove the "." at the end of the comment? (to be consistent with the
> other comm
On Tue, Aug 16, 2022 at 2:02 AM Drouvot, Bertrand wrote:
> On 8/14/22 11:57 AM, Michael Paquier wrote:
> >One thing was itching me about the serialization and
> > deserialization logic though: could it be more readable if we used an
> > intermediate structure to store the length of the seriali
Hello,
On Fri, Aug 12, 2022 at 6:34 AM Drouvot, Bertrand wrote:
> +typedef struct
> +{
> + /*
> +* Authenticated identity. The meaning of this identifier is
> dependent on
>
> has to be replaced by:
>
> +typedef struct ClientConnectionInfo
> +{
> + /*
> +* Authenticat
On Fri, Aug 12, 2022 at 03:34:04PM +0200, Drouvot, Bertrand wrote:
> 3)
>
> +SerializeClientConnectionInfo(Size maxsize, char *start_address)
> +{
> + /*
> + * First byte is an indication of whether or not authn_id has been
> set to
> + * non-NULL, to differentiate that case fr
Hi,
On 8/12/22 12:28 AM, Jacob Champion wrote:
On Wed, Aug 10, 2022 at 10:48 PM Drouvot, Bertrand wrote:
What do you think about adding a second field in ClientConnectionInfo
for the auth method (as suggested by Michael upthread)?
Sure -- without a followup patch, it's not really tested, thou
On Wed, Aug 10, 2022 at 10:48 PM Drouvot, Bertrand wrote:
> What do you think about adding a second field in ClientConnectionInfo
> for the auth method (as suggested by Michael upthread)?
Sure -- without a followup patch, it's not really tested, though.
v2 adjusts set_authn_id() to copy the auth
On Tue, Aug 9, 2022 at 3:39 AM Drouvot, Bertrand wrote:
> Agree that it makes sense to work on those patches in this particular
> order then.
Sounds good. The ClientConnectionInfo patch (previously 0002) is
attached, with the SQL function removed.
Thanks,
--Jacob
From a22ff3ba36f5eb93c582a957c7c
On Mon, Aug 08, 2022 at 12:43:14PM +0200, Drouvot, Bertrand wrote:
> but I'm not sure we should do it as a first step (given the fact that this
> is not Port->authn_id that is passed down to the parallel workers in the
> SYSTEM_USER patch).
>
> What do you think about working on both (aka a) v11-0
On Sat, Aug 06, 2022 at 10:59:26AM -0400, Joe Conway wrote:
> I am not sure how else we should interpret SYSTEM_USER -- if it isn't
> port->authn_id what else would you propose it should be?
What you say sounds rather right, but I was wondering mainly what
Oracle and SQL server report when it come
On 8/6/22 02:26, Michael Paquier wrote:
On Fri, Aug 05, 2022 at 12:48:33PM +0200, Drouvot, Bertrand wrote:
On 8/2/22 11:57 PM, Jacob Champion wrote:
Thoughts from prior reviewers? Is SYSTEM_USER the way to go?
Reading through the other thread, there is a clear parallel between
both in concept
On Fri, Aug 05, 2022 at 12:48:33PM +0200, Drouvot, Bertrand wrote:
> On 8/2/22 11:57 PM, Jacob Champion wrote:
>> Thoughts from prior reviewers? Is SYSTEM_USER the way to go?
Reading through the other thread, there is a clear parallel between
both in concept to provide this information at SQL leve
On 6/22/22 06:31, Drouvot, Bertrand wrote:
> FWIW, I just created a new thread to expose the port->authn_id through
> the SYSTEM_USER sql reserved word.
Review for both seems to have dried up a bit. I'm not particularly
invested in my code, but I do want to see *a* solution go in. So if it
helps
On Thu, Jun 9, 2022 at 6:23 AM Robert Haas wrote:
> On Wed, Jun 8, 2022 at 7:53 PM Jacob Champion wrote:
> > But I don't have any better ideas for how to achieve both. I'm fine
> > with your suggestion of ClientConnectionInfo, if that sounds good to
> > others; the doc comment can clarify why it
On Wed, Jun 8, 2022 at 7:53 PM Jacob Champion wrote:
> But I don't have any better ideas for how to achieve both. I'm fine
> with your suggestion of ClientConnectionInfo, if that sounds good to
> others; the doc comment can clarify why it differs from Port? Or add
> one of the Shared-/Gang-/Group-
On Tue, Jun 7, 2022 at 5:45 PM Robert Haas wrote:
> Perhaps that is
> ill-founded, but I don't think "should be serialized" is necessarily
> something that everybody is going to have the same view on, or even
> know what it means.
Using this thread as an example, once it was decided that the para
On Tue, Jun 7, 2022 at 6:54 PM Jacob Champion wrote:
> "This struct contains connection fields that are explicitly safe for
> workers to access" _is_ a useful semantic, in my opinion. And it seems
> like it'd make it easier to determine what needs to be included in the
> struct; I'm not sure I fol
On Mon, Jun 6, 2022 at 11:44 AM Robert Haas wrote:
> I think I'd feel more comfortable here if we were defining what went
> into which struct on some semantic basis rather than being like, OK,
> so all the stuff we want to serialize goes into struct #1, and the
> stuff we don't want to serialize g
On Fri, Jun 3, 2022 at 10:04 AM Tom Lane wrote:
> I agree with Robert's complaint that Parallel is far too generic
> a term here. Also, the fact that this data is currently in struct
> Port seems like an artifact.
Why do we call this thing a Port, anyway?
I think I'd feel more comfortable here
On Fri, Jun 3, 2022 at 7:36 PM Michael Paquier wrote:
>
> On Fri, Jun 03, 2022 at 10:04:12AM -0400, Tom Lane wrote:
> > I agree with Robert's complaint that Parallel is far too generic
> > a term here. Also, the fact that this data is currently in struct
> > Port seems like an artifact.
> >
> > D
On Fri, Jun 03, 2022 at 10:04:12AM -0400, Tom Lane wrote:
> I agree with Robert's complaint that Parallel is far too generic
> a term here. Also, the fact that this data is currently in struct
> Port seems like an artifact.
>
> Don't we have a term for the set of processes comprising a leader
> p
Michael Paquier writes:
> ParallelPortInfo sounds kind of right for the job to me in this set of
> proposals, as the data is from the Port, and that's some information
> shared between all the parallel workers and the leader.
I agree with Robert's complaint that Parallel is far too generic
a term
On Thu, Jun 02, 2022 at 03:56:28PM -0700, Jacob Champion wrote:
> All right, here's the full list of previous suggestions, I think:
>
> - SharedPort
> - MyProcShared
> - ProcParallelInfo
> - ProcInfoParallel
> - ParallelProcInfo
> - ParallelPortInfo
>
> I have a few new proposals:
>
> - GlobalPo
On Thu, Jun 2, 2022 at 6:52 AM Robert Haas wrote:
> I'm not sure what it SHOULD be called, exactly: that's one of the hard
> problems in computer science.[1]
Yeah...
All right, here's the full list of previous suggestions, I think:
- SharedPort
- MyProcShared
- ProcParallelInfo
- ProcInfoParall
On Tue, May 31, 2022 at 6:21 PM Jacob Champion wrote:
> v10 is rebased over latest; I've also added a PGDLLIMPORT to the new global.
I took a quick look at this and it doesn't seem crazy to me, except
that I think ParallelProcInfo is a bad name for it. It's kind of
generic, because neither "proc"
v10 is rebased over latest; I've also added a PGDLLIMPORT to the new global.
--Jacob
From c8b3d2df4ce461fc65a27699419a54a5b7bb2001 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [PATCH v10 1/2] Add API to retrieve authn_id from SQL
The authn_id field
On Wed, Apr 06, 2022 at 07:16:43PM +, Jacob Champion wrote:
> I assumed that we would follow the existing model of "(de)serialize a
> whole struct", rather than pulling it apart into many separate keys. If
> it got too complicated then we could consider introducing a
> SerializedParallelProcInf
On Wed, 2022-04-06 at 20:09 +0900, Michael Paquier wrote:
> > 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 proposa
On Tue, Apr 05, 2022 at 06:23:06PM +, 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 or
On Tue, 2022-04-05 at 15:13 +0900, Michael Paquier wrote:
> On Wed, Mar 30, 2022 at 04:02:09PM +, 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 identit
On Wed, Mar 30, 2022 at 04:02:09PM +, 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 lik
On Tue, 2022-03-29 at 23:38 +, Jacob Champion wrote:
> v8 rebases over the recent SSL changes to get the cfbot green again.
I think the Windows failure [1] is unrelated to this patch, but for
posterity:
> [03:01:58.925] c:\cirrus>call "C:/Program Files/Git/usr/bin/timeout.exe" -v
> -k60s 15m
On Tue, 2022-03-29 at 16:53 -0700, Andres Freund wrote:
> > We'd also need to guess whether the GUC system's serialization of NULL
> > as an empty string is likely to cause problems for any future auth
> > methods.
>
> You can't represent a NULL in a postgres 'text' datum, independent of
> paralle
Hi,
On 2022-03-29 23:38:29 +, Jacob Champion wrote:
> On Sat, 2022-03-26 at 11:36 -0700, Andres Freund wrote:
> > > I also note that exposing it as a GUC means we have zero control over
> > > who/what can read it. Maybe that's not a problem, but it needs to be
> > > thought about before we go
On Sat, 2022-03-26 at 11:36 -0700, Andres Freund wrote:
> > I also note that exposing it as a GUC means we have zero control over
> > who/what can read it. Maybe that's not a problem, but it needs to be
> > thought about before we go down that path.
>
> Yes, I think that's a fair concern.
I like
Hi,
On 2022-03-26 13:57:39 -0400, Tom Lane wrote:
> Seems like making it a GUC does nothing to fix the complaint you had about
> passing data to workers whether it's needed or not.
I don't think that was my complaint. Maybe Robert's?
> Sure, we don't then need to write any new code for it, but
Andres Freund writes:
> On 2022-03-26 15:18:59 +0900, Michael Paquier wrote:
>> On Thu, Mar 24, 2022 at 05:44:06PM +, Jacob Champion wrote:
>>> On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
Another option would be to make it a GUC. With a bit of care it could be
automatical
Hi,
On 2022-03-26 15:18:59 +0900, Michael Paquier wrote:
> On Thu, Mar 24, 2022 at 05:44:06PM +, Jacob Champion wrote:
> > On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
> >> Another option would be to make it a GUC. With a bit of care it could be
> >> automatically synced by the exis
On Thu, Mar 24, 2022 at 05:44:06PM +, Jacob Champion wrote:
> On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
>> Another option would be to make it a GUC. With a bit of care it could be
>> automatically synced by the existing parallelism infrastructure...
>
> Like a write-once, PGC_INT
Hi,
On 2022-03-24 13:55:29 -0400, Robert Haas wrote:
> On Wed, Mar 2, 2022 at 4:27 PM Andres Freund wrote:
> > I don't think we should commit this without synchronizing the authn between
> > worker / leader (in a separate commit). Too likely that some function that's
> > marked parallel ok querie
On Wed, Mar 2, 2022 at 4:27 PM Andres Freund wrote:
> I don't think we should commit this without synchronizing the authn between
> worker / leader (in a separate commit). Too likely that some function that's
> marked parallel ok queries the authn_id, opening up a security/monitoring hole
> or suc
On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
> On 2022-03-23 23:06:14 +, Jacob Champion wrote:
> > On Wed, 2022-03-23 at 19:00 -0400, Tom Lane wrote:
> > > Hm. I was more envisioning getting the "sharable" info out of Port
> > > entirely, although I'm not quite sure where it should
Hi,
On 2022-03-23 23:06:14 +, Jacob Champion wrote:
> On Wed, 2022-03-23 at 19:00 -0400, Tom Lane wrote:
> > Hm. I was more envisioning getting the "sharable" info out of Port
> > entirely, although I'm not quite sure where it should go instead.
>
> If it helps, I can move the substruct out
On Wed, 2022-03-23 at 19:00 -0400, Tom Lane wrote:
> Hm. I was more envisioning getting the "sharable" info out of Port
> entirely, although I'm not quite sure where it should go instead.
If it helps, I can move the substruct out and up to a new global struct
(MyProcShared?). At this point I thin
Jacob Champion writes:
> On Thu, 2022-03-17 at 18:33 -0400, Tom Lane wrote:
>> I think what we ought to do here is separate out the data that we think
>> parallel workers need access to. It does not seem wise to say "workers
>> can access fields A,B,C of MyPort but not fields X,Y,Z". I do not ha
On Thu, 2022-03-17 at 18:33 -0400, Tom Lane wrote:
> Yeah. It seems to me that putting the auth info into struct Port was
> a fairly random thing to do in the first place, and we are now dealing
> with the fallout of that.
>
> I think what we ought to do here is separate out the data that we thin
Jacob Champion writes:
> On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
>> At the end of the day, Port is an interface used for the communication
>> between the postmaster with the frontends, so I'd like to say that it
>> is correct to not apply this concept to parallel workers because
On Fri, 2022-03-04 at 10:45 +0900, Michael Paquier wrote:
> At the end of the day, Port is an interface used for the communication
> between the postmaster with the frontends, so I'd like to say that it
> is correct to not apply this concept to parallel workers because they
> are not designed to co
On Thu, Mar 03, 2022 at 07:16:17PM +, Jacob Champion wrote:
> I guess it depends on what we want MyProcPort to look like in a
> parallel worker. Are we comfortable having most of it be blank/useless?
> Does it need to be filled in?
Good question. It depends on the definition of how much
authe
On Thu, 2022-03-03 at 16:45 +0900, Michael Paquier wrote:
> Anyway, FixedParallelState
> includes some authentication data passed down by the leader when
> spawning a worker. So, if we were to pass down the authn, we are
> going to need a new PARALLEL_KEY_* to serialize and restore the data
> pass
On Wed, 2022-03-02 at 09:18 +0100, Peter Eisentraut wrote:
> On 01.03.22 23:05, Jacob Champion wrote:
> > On Tue, 2022-03-01 at 19:56 +0100, Peter Eisentraut wrote:
> > > This patch contains no documentation. I'm having a hard time
> > > understanding what the name "session_authn_id" is supposed t
On Wed, Mar 02, 2022 at 01:27:40PM -0800, Andres Freund wrote:
> I don't think we should commit this without synchronizing the authn between
> worker / leader (in a separate commit). Too likely that some function that's
> marked parallel ok queries the authn_id, opening up a security/monitoring hol
Hi,
On 2022-03-01 08:35:27 -0500, Stephen Frost wrote:
> I'm not really sure why we're arguing about this, but clearly the authn
> ID of the leader process is what should be used because that's the
> authentication under which the parallel worker is running, just as much
> as the effective role is
On 01.03.22 23:05, Jacob Champion wrote:
On Tue, 2022-03-01 at 19:56 +0100, Peter Eisentraut wrote:
This patch contains no documentation. I'm having a hard time
understanding what the name "session_authn_id" is supposed to convey.
The comment for the Port.authn_id field says this is the "system
On Tue, Mar 01, 2022 at 10:03:20PM +, Jacob Champion wrote:
> Added a first draft in v5, alongside the perltidy fixups mentioned by
> Michael.
+The authenticated identity is an immutable identifier for the user
+presented during the connection handshake; the exact format depends on
+
On Tue, 2022-03-01 at 19:56 +0100, Peter Eisentraut wrote:
> This patch contains no documentation. I'm having a hard time
> understanding what the name "session_authn_id" is supposed to convey.
> The comment for the Port.authn_id field says this is the "system
> username", which sounds like a c
On Tue, 2022-03-01 at 08:35 -0500, Stephen Frost wrote:
> * Michael Paquier (mich...@paquier.xyz) wrote:
> >
> > Ayway, this function needs to be documented. I think that you should
> > just add that in "Session Information Functions" in func.sgml, same
> > area as current_user(). The last time
On 25.02.22 21:19, Jacob Champion wrote:
On Fri, 2022-02-25 at 16:28 +, Jacob Champion wrote:
Ha, opr_sanity caught my use of cstring. I'll work on a fix later
today.
Fixed in v3.
This patch contains no documentation. I'm having a hard time
understanding what the name "session_authn_id
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Mon, Feb 28, 2022 at 04:00:36PM -0500, Stephen Frost wrote:
> > * Jacob Champion (pchamp...@vmware.com) wrote:
> >> On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> >>> Looks to me like authn_id isn't synchronized to pa
On Mon, Feb 28, 2022 at 04:00:36PM -0500, Stephen Frost wrote:
> * Jacob Champion (pchamp...@vmware.com) wrote:
>> On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
>>> Looks to me like authn_id isn't synchronized to parallel workers right now.
>>> So
>>> the function will return the
On Mon, 2022-02-28 at 16:00 -0500, Stephen Frost wrote:
> > commit efec9f040843d1de2fc52f5ce0d020478a5bc75d
> > Author: Jacob Champion
> > Date: Mon Feb 28 10:28:51 2022 -0800
> >
> > squash! Add API to retrieve authn_id from SQL
>
> Bleh. :) Squash indeed.
Ha, I wasn't sure if anyone re
Greetings,
* Jacob Champion (pchamp...@vmware.com) wrote:
> On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> > Looks to me like authn_id isn't synchronized to parallel workers right now.
> > So
> > the function will return the wrong thing when executed as part of a parallel
> > qu
On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> Looks to me like authn_id isn't synchronized to parallel workers right now. So
> the function will return the wrong thing when executed as part of a parallel
> query.
Thanks for the catch. It looks like MyProcPort is left empty, and
On Fri, Feb 25, 2022 at 01:23:49PM -0800, Andres Freund wrote:
> Looks to me like authn_id isn't synchronized to parallel workers right now. So
> the function will return the wrong thing when executed as part of a parallel
> query.
FWIW, I am not completely sure what's the use case for being able
Hi,
On 2022-02-25 14:25:52 +0800, Julien Rouhaud wrote:
> > Basically the type of stats we're trying to move to dynamic shared memory is
> > about counters that should persist for a while and are accumulated across
> > connections etc. Whereas backend_status.c is more about tracking the current
>
On 2022-02-25 20:19:24 +, Jacob Champion wrote:
> From 2fde60a6bc3739f1894c8c264120e4fa0f04df64 Mon Sep 17 00:00:00 2001
> From: Jacob Champion
> Date: Mon, 14 Feb 2022 08:10:53 -0800
> Subject: [PATCH v3] Add API to retrieve authn_id from SQL
> The authn_id field in MyProcPort is currently o
On Fri, 2022-02-25 at 16:28 +, Jacob Champion wrote:
> Ha, opr_sanity caught my use of cstring. I'll work on a fix later
> today.
Fixed in v3.
--Jacob
From 2fde60a6bc3739f1894c8c264120e4fa0f04df64 Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Mon, 14 Feb 2022 08:10:53 -0800
Subject: [P
On Thu, 2022-02-24 at 20:44 +, Jacob Champion wrote:
> That simplifies things. PFA a smaller v2; if pgaudit can't make use of
> libpq-be.h for some reason, then I guess we can tailor a fix to that
> use case.
Ha, opr_sanity caught my use of cstring. I'll work on a fix later
today.
--Jacob
Hi,
On Thu, Feb 24, 2022 at 09:18:26PM -0800, Andres Freund wrote:
>
> On 2022-02-25 13:01:26 +0800, Julien Rouhaud wrote:
> > On Thu, Feb 24, 2022 at 08:44:08PM +, Jacob Champion wrote:
> > >
> > > Yeah... I was following a similar track with the initial work last
> > > year, but I dropped
Hi,
On 2022-02-25 13:01:26 +0800, Julien Rouhaud wrote:
> On Thu, Feb 24, 2022 at 08:44:08PM +, Jacob Champion wrote:
> >
> > Yeah... I was following a similar track with the initial work last
> > year, but I dropped it when the cost of implementation started to grow
> > considerably. At the
On Thu, Feb 24, 2022 at 08:44:08PM +, Jacob Champion wrote:
>
> Yeah... I was following a similar track with the initial work last
> year, but I dropped it when the cost of implementation started to grow
> considerably. At the time, though, it looked like some overhauls to the
> stats framewor
On Fri, 2022-02-25 at 01:15 +0800, Julien Rouhaud wrote:
> On Thu, Feb 24, 2022 at 04:50:59PM +, Jacob Champion wrote:
> > On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> > > I don't quite see the additional value that this API brings as
> > > MyProcPort is directly accessible, and
Hi,
On Thu, Feb 24, 2022 at 04:50:59PM +, Jacob Champion wrote:
> On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> > I don't quite see the additional value that this API brings as
> > MyProcPort is directly accessible, and contrib modules like
> > postgres_fdw and sslinfo just use t
On Thu, 2022-02-24 at 20:39 +0900, Michael Paquier wrote:
> I don't quite see the additional value that this API brings as
> MyProcPort is directly accessible, and contrib modules like
> postgres_fdw and sslinfo just use that to find the data of the current
> backend.
Right -- I just didn't know i
On Thu, Feb 24, 2022 at 12:15:40AM +, Jacob Champion wrote:
> Stephen pointed out [1] that the authenticated identity that's stored
> in MyProcPort can't be retrieved by extensions or triggers. Attached is
> a patch that provides both a C API and a SQL function for retrieving
> it.
>
> GetAuth
Hi all,
Stephen pointed out [1] that the authenticated identity that's stored
in MyProcPort can't be retrieved by extensions or triggers. Attached is
a patch that provides both a C API and a SQL function for retrieving
it.
GetAuthenticatedIdentityString() is a mouthful but I wanted to
differentia
81 matches
Mail list logo
