Re: machine-readable explain output v4 - Mailing list pgsql-hackers

On Mon, Aug 10, 2009 at 7:57 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Aug 10, 2009 at 1:45 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> The way we have this set up, there's a distinction between properties
>>> and groups, which AFAICS we have to have in order to have directly
>>> comparable structures in XML and JSON.  Didn't you design this
>>> yourself?
>
>> Yes, I did.  But the point is that as far as I can see, the following
>> two things are equivalent:
>
>> <Filter><Text>(f1 > 0)</Text></Filter>
>>  "Filter": { "Text": "(f1 > 0)" }
>
>> And this is not:
>
>> <Filter><Expr><Text>(f1 > 0)</Text></Expr></Filter>
>
> Well, in that case we need to redesign the "grouping" abstraction in
> explain.c, because it's set up to treat a JSON hash as equivalent to
> a parent node type (or whatever you want to call it) in XML.  But
> I'm not sure I want to do it.  It appears to me that what you want
> to do is dumb down the XML representation so it's just as impoverished
> as the JSON one; to wit that there won't be any abstract concept of
> an "Expr" node, and all client programs will have to implicitly know
> that, say, Filter is an instance of an Expr and therefore can be
> expected to have thus-and-such fields inside it.  This does not seem
> like an improvement.  It puzzles me that you are pushing to make
> expression containers anonymous and unrecognizable when you wanted the
> opposite for child plans.

I think I might be starting to understand what you're getting at here.Let me check: I think what you're saying is that
theExpr node is 
potentially useful to clients for identifying where in the tree the
Exprs are, even without specific knowledge about the different types
of filter nodes, much as the Plans node is useful for finding all of
the subplan objects.

If that is correct, then let me make two comments.  First, I don't
think it should be a goal of this format to be self-documenting.  To
the extent that it can be so without mucking up the format, great.
But self-documenting formats are often a recipe for massive bloat, and
in my experience they tend to create more problems than they solve.  I
think keeping it lean is the way to go.

But, second, there might be a way that we can have our cake and eat it
too.  Instead of decorating each node with properties Filter,
Join-Filter, One-Time-Filter, and so on, what we could do is decorate
each node with a single property called Filters, which would be a list
of hashes:

'Filters' : [ { 'Filter-Type' => 'Join', 'Text-Expr' => 'a.foo < b.bar' }]

<Filters>
<Filter>
<Filter-Type>Join</Filter-Type>
<Text-Expr>a.foo < b.bar</Text-Expr>
</Filter>
</Filters>

Would that address your concerns, or am I still way off base here?

...Robert