Re: SYSTEM_USER reserved word implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: SYSTEM_USER reserved word implementation
Date: 2022-06-22 14:51:36
Message-ID: 3361134.1655909496@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Joe Conway <mail(at)joeconway(dot)com> writes:
> On 6/22/22 09:49, Tom Lane wrote:
>> On what grounds do you argue that that's the appropriate meaning of
>> SYSTEM_USER?

> What else do you imagine it might mean?

I was hoping for some citation of the SQL spec.

> Here is SQL Server interpretation for example:
> "SYSTEM_USER
> Returns the name of the current data store user
> as identified by the operating system."

Meh. That's as clear as mud. (a) A big part of the question here
is what is meant by "current" user, in the face of operations like
SET ROLE. (b) "as identified by the operating system" does more to
confuse me than anything else. The operating system only deals in
OS user names; does that wording mean that what you get back is an OS
user name rather than a SQL role name?

My immediate guess would be that the SQL committee only intends
to deal in SQL role names and therefore SYSTEM_USER is defined
to return one of those, but I've not gone looking in the spec
to be sure.

I'm also not that clear on what we expect authn_id to be, but
a quick troll in the code makes it look like it's not necessarily
a SQL role name, but might be some external identifier such as a
Kerberos principal. If that's the case I think it's going to be
inappropriate to use SQL-spec syntax to return it. I don't object
to inventing some PG-specific function for the purpose, though.

BTW, are there any security concerns about exposing such identifiers?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-06-22 14:53:07 Re: Skipping logical replication transactions on subscriber side
Previous Message Tom Lane 2022-06-22 14:39:20 Re: Skipping logical replication transactions on subscriber side