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 Yu9slCBp0WWD4Qx1@paquier.xyz
Whole thread Raw
In response to Re: [PATCH] Expose port->authn_id to extensions and triggers  (Joe Conway <mail@joeconway.com>)
Responses Re: [PATCH] Expose port->authn_id to extensions and triggers
List pgsql-hackers
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 comes to other authentication
methods like SSPI or a cert, where we don't use a user name but some
data dependent on the auth method.  And I have no experience with
these.

Anyway, I was looking at Bertrand's patch, and I can see that it is
doing nothing to move away the connection information that we have in
Port away to a different structure passed down to the parallel
workers, which is what I understand is a cleanup worth on its own
based on the discussion of this thread.  Hence, I still see a good
argument for the introduction of ClientConnectionInfo that gets passed
down to the workers.  Based on that, I think that we'd better finish
v11-0002 (only ClientConnectionInfo, no SQL interface) as a first step
to build for the next ones, with authn being the first piece of
information given to the workers.  With a separate structure, the
auth_method can also be a second member in ClientConnectionInfo,
completing what would be needed to build SYSTEM_USER as the workers
would have access to it.

Am I getting that right?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: John Naylor
Date:
Subject: Re: failing to build preproc.c on solaris with sun studio