Horton

Re: Add support for logging the current role

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, Noah Misch <noah@leadboat.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-02-11T15:54:50Z
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

On Fri, Feb 11, 2011 at 10:52 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Fri, Feb 11, 2011 at 10:34 AM, Kevin Grittner
>> > Should we abbreviate something there?  max_pred_locks_per_tran,
>> > maybe?
>>
>> If we're going to abbreviate transaction, I'd vote for txn over tran,
>> but I think Stephen's point that this is already a lost cause may have
>> some validity.  Not sure what other people think.
>
> There's lots of other GUCs with "transaction" spelled out in them.. :/
>
> Another option, which I don't like, would be to use 'default' by
> 'default', and build the list on the fly every time if that's what it
> is..  That would give no insight into what the list of fields is for
> someone though, they'd have to go back to the documentation to figure
> it out, and that sucks..

Yeah.  The root cause of this problem is that the way psql handles
tabular output with a few very wide rows stinks.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company