Re: Add support for logging the current role

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add support for logging the current role
Date: 2011-01-13 00:58:54
Message-ID: 20110113005854.GM4933@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I certainly disagree about this, not being able to figure out what's
> > causing a 'permissions denied' error because you don't know which role
> > the log is coming from is *very* annoying.
>
> Interesting. I wonder if we shouldn't try to fix this by including
> the relevant role name in the error message. Or is that just going to
> be too messy to live?

It might be possible to do and answer that specific question- but what
about the obvious next question: which role was this command run with?
iow, if I log dml, how do I know what the role was when the dml
statement was run? ie- why was this command allowed?

Let's ask another question- why do we provide a %u option in
log_line_prefix instead of just logging it as part of each statement?
When you have roles that aren't 'inherit' and have a lot of 'set role's
happening, you end up asking the same questions about role that you
would about user.

As a side-note, CurrentUserId isn't actually exported (I'm not suprised,
tbh, but I've actually checked now), so you have to go through
GetUserIdAndSecContext().

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-01-13 01:12:03 Re: Fixing GIN for empty/null/full-scan cases
Previous Message Tom Lane 2011-01-13 00:47:12 Re: Bug in pg_describe_object, patch v2