Re: Add support for logging the current role

Stephen Frost <sfrost@snowman.net>

From: Stephen Frost <sfrost@snowman.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-13T00:58:54Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add support for an application_name parameter, which is displayed in

  2. Make CSV column ordering a bit more logical.

  3. Extend the format of CSV logs to include the additional information supplied

  4. Add virtual transaction IDs to CSVLOG output, so that messages coming from

  5. Provide for logfiles in machine readable CSV format. In consequence, rename

* Robert Haas (robertmhaas@gmail.com) wrote:
> On Wed, Jan 12, 2011 at 12:59 PM, Stephen Frost <sfrost@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