On Mon, Aug 23, 2021 at 11:33:09AM +0200, Magnus Hagander wrote:
> As long as it's optional, I don't think that drawback holds as an
> argument. The same argument could be made against the cvs logs in the
> first place -- they add information to every row that a lot of people
> don't need. But it's optional. Leaving it up to the administrator to
> choose whether they prefer the verbose-and-easier-to-parse-maybe
> format or the more compact format seems like the right path for that.
From a code perspective, and while on it, we could split a bit elog.c
and move the log entries generated for each format into their own
file. That would be cleaner for CSV and JSON. As a whole I don't
have an objection with moving the JSON format into core. If one
proposes a patch, feel free to reuse the code from the module I have
released.
> I bet quite a few would actually choose json -- easier to integrate
> with other systems (because newer systems love json), and unless
> you're actually logging a lot of queries (which many people don't),
> the size of the logfile is often not a concern at all.
The module I publish on github to do this work is the most popular
thing of my plugin repo, FWIW. It even gets bug reports, sometimes.
> In short, I would also support the presence of JSON log format in
> core. (but as a proper log_destination of course -- or if it's time to
> actually split that into a separaet thing, being one parameter for
> log_destination and another for log_format)
What would you gain with a new parameter here? I think that this
would be rather confusing and log_destination has been around for
years.
--
Michael
