Re: Similar to csvlog but not really, json logs?
От | Peter Geoghegan |
---|---|
Тема | Re: Similar to csvlog but not really, json logs? |
Дата | |
Msg-id | CAM3SWZT0Dp+70z7TJioqhW9PQERO9Ng8V=DhgzCaB5zDmW7DEw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Similar to csvlog but not really, json logs? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Aug 26, 2014 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I think that it would be a good beginner's project to make pprint() >> print JSON. > > There's something to be said for that (or, really, for any standardized > widely-popular textual data format; but JSON is a perfectly reasonable > candidate). Yeah. The structures that the optimizer produces in particular are very intricate. It would be quite nice to have a way to manipulate it mechanically. >> The existing infrastructure is user visible because of GUCs like >> debug_print_parse. > > There is that :-(. The fact that these strings are stored in the catalogs > isn't a problem as long as we make the change in a major version upgrade. > But to the extent that there is client-side code that expects to make > sense of the strings, it could be a problem. Is there any such code? > If so, are we really beholden to not break it? It's not like we don't > change those data representations routinely anyway ... I highly doubt that there is any such code in the wild. It seems to only be intended for debugging user-defined rules, which are not a popular feature. Personally, I've occasionally used tricks like diffing two files with similar Nodes to see where and how differences that are of interest arise. :-) -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: