Re: SYSTEM_USER reserved word implementation

On Wed, Jun 22, 2022 at 9:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Joe Conway <mail(at)joeconway(dot)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.