Excellent phrasing (thanks to Christophe!): "There is a large class of log analysis tool out there that has trouble with multiline formats and we should be good ecosystem players"
> I'm much less fussed by this in contrib/ (with the same concern you noted), at a minimum as an example of how to do logging in other formats. This would be a very well balanced compromise, almost every distribution flavour also packages contrib so installing contrib and loading such module as a convenient pre-packaged shared library would just be an excellent solution to the big majority of Postgres users. Now we are moving to the solutions space :) I wanted to wait this week, though, to give sufficient time to comment on all aspects and would do another wrap-up next weekend. This suggestion would definitely be part of it. El mié., 18 abr. 2018 a las 14:10, Christophe Pettus (<x...@thebuild.com>) escribió: > > > On Apr 18, 2018, at 11:59, Robert Haas <robertmh...@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't have 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 and we should be good > ecosystem players," that's fine. (I'm a bit sour about the number of tools > being written with one-line-per-event baked 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 (such as > 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 logging in other formats. > > -- > -- Christophe Pettus > x...@thebuild.com > > -- [image: XOE Solutions] <http://xoe.solutions/> 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.
