"Joe Conway" <joe@conway-family.com> writes:
>> We do not currently have correct implementations of IS TRUE, IS FALSE,
>> or IS UNKNOWN (IS TRUE/FALSE are in there but give the wrong result
>> for null inputs). This is on my to-do list to fix; not sure if the
>> master TODO list mentions it or not. Actually it'd be a good project
>> for a newbie hacker who wants to learn about the backend's
>> expression-handling machinery. Anyone want to take it on?
> I'd like to finish up the has_table_privilege function over the next week or
> so and then take this on. Can you point me in a direction to start looking?
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.
IS [NOT] NULL is handled a little differently: gram.y generates a
specialized Expr node, which parse_expr.c translates to a function call
on the specialized functions nullvalue() and nonnullvalue()
respectively. I don't much care for this implementation either, again
partly because ruleutils.c has to be uglified to deal with it, but
partly because the optimizer can't cheaply recognize IS NULL tests
either.
I'd like to see all eight of these guys translated into a specialized
kind of expression node, called perhaps BooleanTest. Actually, it'd
probably be wise to keep IS NULL separate from the six boolean tests,
with an eye to the future when it will need to support nonscalar
arguments. So maybe BooleanTest and NullTest node types, each with a
field showing exactly which test is wanted.
Adding a new expression node type is a straightforward but rather
tedious exercise in teaching some dozens of places what to do with it.
A grep for existing expression node types, such as CaseExpr or
FieldSelect or RelabelType, will give you a good idea what needs to be
done.
regards, tom lane
