Horton

Re: Add support for logging the current role

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-15T01:44:40Z
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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > If you have a format string, what do you want to do with the bits of the 
> > format that aren't field references?
> 
> I was thinking of it as being strictly a field list.  I don't know
> whether it's really practical to borrow log_line_prefix's one-character
> names for the fields (for one thing, there would need to be names for
> all the existing CSV columns, not all of which equate to log_line_prefix
> escapes);

I'm not really happy about the idea that you can only get certain
information in a log file if you use CSV format.  I also don't know
that there's really any particular reason log_line_prefix's names
have to be one character.

> but in any case anything other than field references would be
> disallowed.  If you prefer to use a name list as the syntax that's fine
> with me.

I do like the idea of having just a field list though, to keep things
simple for the CSV users, and we could also pre-process the list into
flag variables or a bitmask or similar to be able to quickly check if a
certain field should be included or not.  I'm not really keen about how
log_line_prefix currently parses the direct user-provided syntax every
time; strikes me as inefficient.

	Thanks,

		Stephen