Re: SYSTEM_USER reserved word implementation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SYSTEM_USER reserved word implementation
Дата
Msg-id 3361134.1655909496@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SYSTEM_USER reserved word implementation  (Joe Conway <mail@joeconway.com>)
Ответы Re: SYSTEM_USER reserved word implementation  (Joe Conway <mail@joeconway.com>)
Список pgsql-hackers
Joe Conway <mail@joeconway.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side