Re: Easily reading debug_print_plan

On 11/20/2013 10:36 PM, Tom Lane wrote:
> 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.

Because I'm working on updatable security_barrier views using the
approach outlined to the list earlier. EXPLAIN really doesn't do the
trick for working on the guts of the rewriter.

>> 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.

I do think it might be worthwhile at some point, but once I remembered
it was about more than just debug_print_ output - that DB performance is
impacted - I realised it was not a topic for a quick and simple change.
Benchmarking required, etc.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services