On Sun, Apr 15, 2018 at 1:07 PM, Christophe Pettus <x...@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 matter in 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
