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
signature.asc
Description: PGP signature
