On Wed, Jun 22, 2022 at 9:28 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Joe Conway <m...@joeconway.com> writes: > > On 6/22/22 11:52, Tom Lane wrote: > >> I think a case could be made for ONLY returning non-null when authn_id > >> represents some externally-verified identifier (OS user ID gotten via > >> peer identification, Kerberos principal, etc). > > > But -1 on that. > > > I think any time we have a non-null authn_id we should expose it. Are > > there examples of cases when we have authn_id but for some reason don't > > trust the value of it? > > I'm more concerned about whether we have a consistent story about what > SYSTEM_USER means (another way of saying "what type is it"). If it's > just the same as SESSION_USER it doesn't seem like we've added much. > > Maybe, instead of just being the raw user identifier, it should be > something like "auth_method:user_identifier" so that one can tell > what the identifier actually is and how it was verified. > > I was thinking this was trying to make the following possible:
psql -U postgres # set session authorization other_superuser; # set role other_role; # select system_user, session_user, current_user; postgres | other_superuser | other_role Though admittedly using "system" for that seems somehow wrong. connection_user would make more sense. Then the system_user would be, if applicable, an external identifier that got matched with the assigned connection_user. I can definitely see having the external identifier be a structured value. David J.
