Horton

Re: Add support for logging the current role

Tom Lane <tgl@sss.pgh.pa.us>

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

Stephen Frost <sfrost@snowman.net> writes:
> I'd been puzzling over how to deal with this big list of fields in
> postgresql.conf and I do like the idea of some kind of short-cut being
> provided to ease the pain for users.

Yeah, I agree with the worry that a default value that's a mile long
is going to be a bit of a PITA.  But I don't think we're there yet on
having a better solution.

> What about something other than
> version_x_y?  I could maybe see having a 'default' and an 'all'
> instead..  Then have the default be what we have currently and 'all' be
> the full list I'm thinking about.

If "default" always means what it means today, I can live with that.
But if the meaning of "all" changes from version to version, that seems
like a royal mess.  Again, I'm concerned that an external tool like
pgfouine be able to make sense of the value without too much context.
If it doesn't know what some of the columns are, it can just ignore them
--- but a magic summary identifier that it doesn't understand at all is
a problem.

			regards, tom lane