| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | David Fetter <david(at)fetter(dot)org> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Arnold <dar(at)xoe(dot)solutions>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal: Adding json logging |
| Date: | 2018-04-14 20:20:16 |
| Message-ID: | 20180414202016.4rmsc37g6wvckq3r@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)fetter(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-04-14 20:56:08 | Re: Setting rpath on llvmjit.so? |
| Previous Message | Andres Freund | 2018-04-14 20:09:42 | Re: Setting rpath on llvmjit.so? |