On Tue, Aug 11, 2009 at 12:11 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> 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 the Expr 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.
>
> Well, my point is that there are a bunch of different places that
> expressions can appear in a plan tree --- filters, join filters, sort
> keys, hash clauses, merge clauses, index clauses, output expressions,
> and I'm not sure I remembered them all, and I fully expect that some
> more might appear in future. I don't think it's appropriate to require
> clients to keep track of exactly which tree properties are expressions,
> especially not when we can easily label them.
>
>> 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.
>
> It isn't. But I think it should be a goal that a client can, say,
> find all the references to a given variable without a huge amount of
> hard-wired knowledge about specific properties of specific node types.
> So it should be able to find all the expressions with a relatively
> dumb search of the tree (eg, XPath?).
>
>> 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' }]
>
> I still say that's a bad idea for child Plans; and it's a worse one for
> expressions. The point about retaining knowledge of child order is
> absolutely critical for many of the places where exprs appear, such as
> sort keys and output columns. You'd have to seriously uglify the
> notation in order to do it like this.
>
> One way that we could handle this, I guess, is to embed more information
> in the property names --- eg use "Expr Text" where I just had "Text".
> But it's not apparent to me why that should be considered better style
> than the other way.
Unfortunately, I have to admit to total confusion. The idea in the
last paragraph seems reasonable to me, but since I don't understand
the other alternative, I can't say whether it's better or worse. I
wonder if we would be better off waiting for feedback from actual tool
authors. I have no illusions that the format is perfect...
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
