Interesting. I am thinking we could put markers like '|' in the log
output, and then have some secondary process either remove them or add
special formatting to match the requested output format.
---------------------------------------------------------------------------
David Fetter wrote:
> Folks,
>
> I've run into something that concerns me. It's pretty much an 8.2
> issue, but I'm hoping to stimulate some discussion on it. It's
> PostgreSQL's log files. Right now, they're (sometimes just barely ;)
> human-readable, but they take significant effort to parse. For
> example, pqa, a very clever piece of code, is mostly devoted to
> parsing said files and works only with significant tweaking and
> restrictions on log file formats in 8.0.
>
> Simple logging is a default that should probably not change, but I'm
> thinking that for people who want to find something out from the logs,
> we could see about a kind of plugin architecture which would enable
> things like:
>
> * CSV
> * YAML
> * XML
> * Piped logs, as Apache can do
> * DB handle. I know this one will be controversial.
>
> I'm thinking that a GUC variable (or should there be a class of them?)
> called log_format would be part of the user interface to this and
> would be able to switch from the cheap default code path to one that's
> more expensive, just as log_statement does.
>
> So, a few questions:
>
> 1. Am I the only one who would wants an option for machine-readable logs?
> 2. Am I way off with the idea for an architecture for same?
> 3. What big things am I missing here?
>
> Cheers,
> D
> --
> David Fetter david@fetter.org http://fetter.org/
> phone: +1 510 893 6100 mobile: +1 415 235 3778
>
> Remember to vote!
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073