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 →
-
Add support for an application_name parameter, which is displayed in
- 8217cfbd9918 9.0.0 cited
-
Make CSV column ordering a bit more logical.
- 230e8962f3a4 8.3.0 cited
-
Extend the format of CSV logs to include the additional information supplied
- 3bf66d6f1c3a 8.3.0 cited
-
Add virtual transaction IDs to CSVLOG output, so that messages coming from
- 77c166ba6cf6 8.3.0 cited
-
Provide for logfiles in machine readable CSV format. In consequence, rename
- fd801f4faa8e 8.3.0 cited
* 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