Robert Haas <robertmhaas@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.
regards, tom lane
