Re: Proposal: Adding json logging - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Proposal: Adding json logging
Date
Msg-id 20180414202016.4rmsc37g6wvckq3r@alap3.anarazel.de
Whole thread Raw
In response to Re: Proposal: Adding json logging  (David Fetter <david@fetter.org>)
Responses Re: Proposal: Adding json logging  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Proposal: Adding json logging  (David Fetter <david@fetter.org>)
List pgsql-hackers
On 2018-04-14 18:05:18 +0200, David Fetter wrote:
> On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote:
> > David Fetter <david@fetter.org> writes:
> > > I think a suite of json_to_* utilities would be a good bit more
> > > helpful in this regard than changing our human-eye-consumable
> > > logs. We already have human-eye-consumable logs by default.  What
> > > we don't have, and increasingly do want, is a log format that's
> > > really easy on machines.
> > 
> > I'm dubious that JSON is "easier on machines" than CSV.
> 
> I've found the opposite.
> 
> CSV is very poorly specified, which makes it at best complicated to
> build correct parsing libraries. JSON, whatever gripes I have about
> the format[1] is extremely well specified, and hence has excellent
> parsing libraries.

Worth to notice that useful json formats for logging also kinda don't
follow standards. Either you end up with entire logfiles as one big
array, which most libraries won't parse and makes logrotate etc really
complicated, or you end up with some easy to parse format where newlines
have non-standard record separator meaning.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Setting rpath on llvmjit.so?
Next
From: Tom Lane
Date:
Subject: Re: Setting rpath on llvmjit.so?