> What we (and I imagine many others, though clearly not OP) would need is a "do- > business-as" user that maps not to the database users, but to in-appli

> What we (and I imagine many others, though clearly not OP) would need is a "do- > business-as" user that maps not to the database users, but to in-application > users, and then a mechanism to pass this user to the DB, and log it in addition > to the database user. This is kind of what Supabase does, for use in tandem with row-level security. It stores the user's JWT in a custom configuration parameter via set_config() when the database connection is established on behalf of the user, so you can see the token by calling get_config() with the config parameter name. Supabase also provides convenience functions to destructure the token and get the things you need (like auth.uid()), so it would be easy to fetch the user ID or user name in a trigger to log it.