Robert Haas <robertmh...@gmail.com> writes:
> On Mon, Aug 10, 2009 at 1:45 PM, Tom Lane<t...@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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
