> The way things currently work is that gram.y translates "x IS TRUE" etc
> to "x = true" etc. This is wrong because it does the wrong thing for
> null input. Another objection is that it's impossible for ruleutils.c
> to reverse-list the expression tree in its original form.
fyi, in case it helps: we used to have gram.y translate these into
function calls, rather than the operator expression. But that precluded
the optimizer from ever having a shot at optimizing out "const = const"
kinds of expressions and other fluff.
If we go to a specialized node in the parse tree, then the optimizer
could be taught to handle that, which is better than the original
straight function call which would have masked things too much.
- Thomas