Re: Trigger function always logs postgres as user name

From: Francisco Olarte <folarte(at)peoplecall(dot)com>
To: Alexander Reichstadt <lxr(at)me(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trigger function always logs postgres as user name
Date: 2019-02-09 12:44:25
Message-ID: CA+bJJbxe4g68j6n5fQt7hO_8V12rW8NM02u=MxgKXoeVudLXhA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Alexander:

On Sat, Feb 9, 2019 at 1:32 PM Alexander Reichstadt <lxr(at)me(dot)com> wrote:
> I setup trigger functions for logging, and while they do work and get triggered, the current_user always insert “postgres” even when updates/deletes/inserts are caused by users of another name.
> How do I get it to use the name that caused the update? It seems current_user is the trigger’s user, so the server itself in some way. This is on PG10

Maybe your trigger has been defined by postgres and you are using
(from https://www.postgresql.org/docs/11/functions-info.html)
current_user, name, user name of current execution context
instead of
session_user, name, session user name

"The session_user is normally the user who initiated the current
database connection; but superusers can change this setting with SET
SESSION AUTHORIZATION. The current_user is the user identifier that is
applicable for permission checking. Normally it is equal to the
session user, but it can be changed with SET ROLE. It also changes
during the execution of functions with the attribute SECURITY DEFINER.
In Unix parlance, the session user is the “real user” and the current
user is the “effective user”. current_role and user are synonyms for
current_user. (The SQL standard draws a distinction between
current_role and current_user, but PostgreSQL does not, since it
unifies users and roles into a single kind of entity.)"

Francisco Olarte.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Justin Pryzby 2019-02-09 21:46:51 Re: Server goes to Recovery Mode when run a SQL
Previous Message auxsvr 2019-02-09 11:39:01 Re: FDW, too long to run explain