Joe Conway <mail@joeconway.com> writes:
>> Any ideas about naming are welcome.
> Maybe:
> Plan steps Expressions
> ----------------- --------------------
> Planner output "Plan" "Expr"
> Executor state "PlanState" "ExprState"
> I think "Plan node" should only refer to nodes literally derived from
> nodetype Plan. Similarly with "PlanState nodes".
That part works for me. The other part isn't quite right since most
expression-class nodes don't inherit from Expr, and their state nodes
certainly don't need an fcache.
But come to think of it, we don't need an fcache for AND/OR/NOT nodes,
and SUBPLAN has different needs altogether. I wonder if it's time to
split the Expr node class into three or so classes: op/func, boolean,
and subplan. If we did that, we could use the Expr struct name for the
superclass of all expression-type nodes (since it'd contain only
NodeTag, it'd be a purely decorative superclass) and then ExprState
works as the name of the associated superclass of expression-state nodes
(only slightly less decorative, it'd contain NodeTag and the "Expr *"
link to the associated expression node). The existing FunctionCache
struct would then become part of the ExprState subclass that's
associated with the op/func Expr subclass. This seems like it works...
regards, tom lane