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
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 |