Re: Proposal: Adding json logging
Given we have the following LOG_DESTIONATION...
| /* 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@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
 | 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. | |
В списке pgsql-hackers по дате отправления: