Re: Proposal: Adding json logging

Given we have the following LOG_DESTIONATION...

Source:
https://github.com/postgres/postgres/blob/9d4649ca49416111aee2c84b7e4441a0b7aa2fac/src/include/utils/elog.h#L394-L398

/* Log destination bitmap */
#define LOG_DESTINATION_STDERR 1
#define LOG_DESTINATION_SYSLOG 2
#define LOG_DESTINATION_EVENTLOG 4
#define LOG_DESTINATION_CSVLOG 8

Something confuses me about CSVLOG...
Isn't log destination and log formatting tow different kinds? How to deal
with that mix?
I was somewhat expecting to find a log formatting hook somewhere around,
but it seems more complicated than that.

El sáb., 14 abr. 2018 a las 11:51, Chapman Flack (<chap(at)anastigmatix(dot)net>)
escribió:

> On 04/14/18 12:05, David Fetter wrote:
> > On Sat, Apr 14, 2018 at 11:51:17AM -0400, Tom Lane wrote:
> >> 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.
>
> I was just about to say the same thing. Based on my experience, I can infer
> the history of CSV as a format was something like this:
>
> "we'll use commas to separate the values"
>
> - some implementations released
>
> "but what if a value has a comma?"
>
> - some new implementations released
>
> "what if it has a quote?"
>
> - some newer implementations released
>
> "a newline?"
>
> - ...
>
> > JSON, whatever gripes I have about
> > the format[1] is extremely well specified, and hence has excellent
> > parsing libraries.
>
> It has, if nothing else, the benefit of coming around later and seeing
> what happened with CSV.
>
> -Chap
>
--
[image: XOE Solutions] <http://xoe.solutions/> DAVID ARNOLD
Gerente General
xoe.solutions
dar(at)xoe(dot)solutions
+57 (315) 304 13 68
*Confidentiality Note: * This email may contain confidential and/or private
information. If you received this email in error please delete and notify
sender.
*Environmental Consideration: * Please avoid printing this email on paper,
unless really necessary.