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 (<c...@anastigmatix.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@xoe.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.
