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 level, indeed.
> I did not look in detail to this thread, but if the goal is "only" to expose
> authn_id (as the subject describes) then it seems to me that SYSTEM_USER [1]
> is the way to go.
>
> [1]: https://commitfest.postgresql.org/39/3703/
However, I am not sure if the suggestion of auth_method:authn as
output generated by SYSTEM_USER would be correct according to the SQL
specification, either. The spec being not really talkative about the
details of what an external module should be opens up for a lot of
interpretation, something that both thread are dealing with.
Anyway, we are talking about two different problems on this thread:
1) Provide the authn/SYSTEM_USER through some SQL interface, which is
what 0001 is an attempt of, SYSTEM_USER is a different attempt.
2) Move authn out of Port into its own structure, named
ClientConnectionInfo, and pass it down to the parallel workers.
SYSTEM_USER overlaps with 0001, but I see no reason to not do 0002 in
all cases. Even if we are not sure yet of how to expose that at SQL
level, we still want to pass down this information to the parallel
workers and we still want to not have that in Port. An extension
could also do easily the job once 0002 is done, so I see a good
argument about doing it anyway. The name ClientConnectionInfo from
Robert looks like the compromise we have for the new structure holding
the information about the client information passed down to the
workers.
--
Michael
