On Sat, Aug 21, 2021 at 2:37 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Fri, Aug 20, 2021 at 11:35:29AM +0200, Ronan Dunklau wrote: > > Michael, your jsonlog module already fullfills this need. Is it something > > that > > should be merged into our tree ? > > Yes, there is nothing technically preventing to have this stuff in > core, of course, and that would even take care of the issues in > detecting if the piping protocol should be used or not. > > Now, the last time this was proposed, there was a lot of drawback > because the presence of the JSON keys increases significantly the size > of the logs compared to CSV, and usually users care a lot about the > size of the log files. I would support the presence of JSON format > for the logs in core, FWIW.
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. 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. 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) -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
