* Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost <sfr...@snowman.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
signature.asc
Description: Digital signature
