On Sun, Apr 15, 2018 at 1:07 PM, Christophe Pettus <xof@thebuild.com> wrote:
>> On Apr 15, 2018, at 09:51, David Arnold <dar@xoe.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
matterin PostgreSQL it is very easy to write code that parses .csv format.
I'm not sure exactly how you intended to this comment, but it seems to
me that whether CSV is ease or hard to parse, somebody might
legitimately find JSON more convenient. For example, and as has been
discussed on this thread, if you have a system that is consuming the
logs that already knows how to parse JSON but does not know how to
parse CSV, then you will find the JSON format to be convenient.
For the record, I'm tentatively in favor of including something like
this in contrib. I think it's useful to have more examples of how to
use our existing hooks in contrib, and I think this is useful on
principle.
I am a little concerned about this bit from the README, though:
====
Note that logging_collector should be enabled in postgresql.conf to
ensure consistent log outputs. As JSON strings are longer than normal
logs generated by PostgreSQL, this module increases the odds of malformed
log entries.
====
I'm not sure I understand the issue, but I don't like malformed log entries.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company