Horton

Re: Add support for logging the current role

Stephen Frost <sfrost@snowman.net>

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

* Andrew Dunstan (andrew@dunslane.net) wrote:
> On 02/15/2011 11:13 AM, Stephen Frost wrote:
> >Think I suggested that at one point.  I'm all for doing that on a major
> >version change like this one, but I think we already had some concerns
> >about that on this thread (Andrew maybe?).
> 
> I could live with it for a release if I thought we had a clear path
> ahead, but I think there are some design issues that we need to
> think about before we start providing for header lines and variable
> formats in CSV logs, particularly w.r.t. log rotation etc. So I'm
> slightly nervous about going ahead with this right now.

I believe the suggestion that Robert and I were talking about above was
to just unilatterally change the CSV log file output format to include
current_role.  No header lines, no variable output format, etc.

I do think we can make header lines and variable output work, if we can
get agreement on what the semantics should be.

> You don't really make your case any better by continuing this
> argument from years ago. I can tell you from experience that the CSV
> HEADER feature is distinctly useful as it is. If you want to add a
> mode that uses the header line as a column list on import, then make
> that case, and I'll support it in fact, but it's not an alternative
> to having the header ignored, which is a feature I would vigorously
> resist removing. 

I'm not really interested in removing it.  I guess I have a vain hope
that with arguing I'll convince someone to take up the mantle of
implementing the 'use header' option. :)  Not getting much traction
though, so I expect I'll work on it this summer.

> (Incidentally, I think it won't be trivial - the
> COPY code expects to know the columns by the time it opens the
> file).

Thanks for that insight, I'll take a look at how things work and see if
I can come up with a sensible proposal.

	Thanks,

		Stephen