> On Apr 18, 2018, at 11:59, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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.
Of course. The specific comment I was replying to made a couple of jumps that I wanted to unwind: The first is that we
don'thave a machine-readable format for PostgreSQL (we do, CSV), and that there was "no substantial objection to this
need."
If the requirement is: "There is a large class of log analysis tool out there that has trouble with multiline formats
andwe should be good ecosystem players," that's fine. (I'm a bit sour about the number of tools being written with
one-line-per-eventbaked into them and whose solution to any other format is "use regex," but that's neither here nor
there,I suppose.)
My primary objection to creating new output formats is that it creates an implicit burden on downstream tools to adopt
them. For example, a log of query analysis tools don't yet process JSON-format plans, and they've been around for a
while. By introducing a new format in core (which was the starting proposal), we're essentially telling all the tools
(suchas pgbadger) that might absorb them that we expect them to adopt that too.
> For the record, I'm tentatively in favor of including something like
> this in contrib.
I'm much less fussed by this in contrib/ (with the same concern you noted), at minimum as an example of how to do
loggingin other formats.
--
-- Christophe Pettus
xof@thebuild.com
