...
> Adding a new expression node tree type is not too difficult these days;
> see for example Joe Conway's recent NullTest and BooleanTest additions.
> I believe the existing expansions of row comparison operators
> (makeRowExpr) should be replaced by specialized nodes, too. That would
> give us a shot at implementing row '<', '>' comparisons in a
> spec-compliant fashion...
OK, now that we are pushing new nodes into the executor with abandon :)
...
Let's talk about the preferred technique for doing so, especially with
row-style argument lists. I want to implement IS NULL for rows also
(actually, already did so using a transformation in gram.y -- no need to
jump on that one Tom ;), and found a comment from Joe on the NullTest
code saying that he wanted to do just that "someday". Should we honk
around the existing NullTest node to handle both lists of arguments and
single arguments, or should we have a completely different set of nodes
for handling row arguments? I'll guess the latter, but we should talk
whether that scales properly, about the preferred style for this new
kind of node, and about how to minimize performance hits which we might
see if we have a large number of new node types being handled by the
executor.
If we extend existing nodes to handle lists, then I might be able to
package the DISTINCT test into an A_Expr node, though I haven't pushed
that all the way through to see for sure.
Using the SubLink node does not seem quite right because IS DISTINCT
FROM does not seem to make sense with an embedded select as one of the
arguments, but maybe it does??
Comments? I'm itchy to code but don't want to waste more time than
necessary heading the wrong direction...
- Thomas
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
