Re: Easily reading debug_print_plan

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> I'm spending a lot of time staring at parse and plan trees at the
> moment, and I'm finding reading them rather cumbersome.

Is there a particular reason you're doing that rather than looking at
EXPLAIN output? Only the latter is meant to be at all user-friendly.

> For those of you who do this a lot, do you use any sort of tooling to
> help you out? Just being able to collapse and expand subtrees would be a
> lifesaver.

vim was mentioned --- I prefer emacs, which can also find the matching
brace pretty easily.

> If it's a hassle for others too, how would you feel about using json as
> an output format in future releases? It'd be pretty simple to retrofit
> by the looks, though updating the regression tests would be a PITA. My
> main concern would be effects on back-patching.

The internal trees appear nowhere in the regression test outputs AFAIK.

> The same representation is used for storing rules. So it can't be
> changed for BC reasons and compactness/performance.

We could in principle change to a different text representation for
stored rules. Compactness would be an issue if it were materially
bigger than the existing formatting, but offhand it seems like JSON
is morally equivalent to what we do now, no?

If you think this is worthwhile, you might care to take a look at
outfuncs.c/readfuncs.c and figure out what it'd take to switch to
json-compatible formatting.

regards, tom lane