From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | David Arnold <dar(at)xoe(dot)solutions> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal: Adding json logging |
Date: | 2018-04-15 17:24:28 |
Message-ID: | CD7041D6-96E1-43C9-9ABA-5BF0D46288AB@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Apr 15, 2018, at 10:07, Christophe Pettus <xof(at)thebuild(dot)com> wrote:
>
>
>> On Apr 15, 2018, at 09:51, David Arnold <dar(at)xoe(dot)solutions> wrote:
>>
>> 1. Throughout this vivid discussion a good portion of support has already been manifested for the need of a more structured (machine readable) logging format. There has been no substantial objection to this need.
>
> I'm afraid I don't see that. While it's true that as a standard, CSV is relatively ill-defined, as a practical matter in PostgreSQL it is very easy to write code that parses .csv format.
More specifically, JSON logging does seem to be a solution in search of a problem. PostgreSQL's CSV logs are very easy to machine-parse, and if there are corrupt lines being emitted there, the first step should be to fix those, rather than introduce a new "this time, for sure" logging method.
It's a matter of a few lines of code to convert CSV logs to a JSON format, if you need JSON format for something else.
Remember, also, that every new logging format introduces a burden on downstream tools to support it. This is (still) an issue with JSON format plans, which had a much more compelling advantage over standard-format plans than JSON logs do over CSV.
--
-- Christophe Pettus
xof(at)thebuild(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | David Arnold | 2018-04-15 17:39:33 | Re: Proposal: Adding json logging |
Previous Message | Christophe Pettus | 2018-04-15 17:07:44 | Re: Proposal: Adding json logging |