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: Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-01-15T03:15:59Z
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:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> In any case, if the GUC representation is a list of field names, I think
>> the POLA demands that the system honor the list order.  

> Agreed.  That puts us back into the question of how to make it
> efficient.  My best thought at the moment, which doesn't strike me as
> particularly efficient, is to build an array of the columns as enum's
> and then have loop through the array and use a switch() on the enum.

Yeah, an array or list of integer codes was what I was thinking too.

> At least it's all integer-based there then and we're not calling
> strcmp() for every field or strchr to find the next field, but
> couldn't we do better?

I really doubt that the cycles spent in the loop + switch are going to
amount to anything at all, compared to the cycles involved in formatting
each field and then pushing it through the CSV logic.  Not to mention
the I/O costs of sending the string somewhere afterwards.

			regards, tom lane