On Tue, Aug 26, 2014 at 7:47 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
