Dima Tkach <dmitry@openratings.com> writes:
> And another possibility is to create isnull () operator... but that
> would have to wait until postgres allows functions with unknown argument
> types
Actually, we do have that now --- it'd be reasonable to implement such
a function and operator as taking type ANY. Hm, maybe this is more
practical than I thought. If we replace the special-purpose NullTest
expression node by two operators (IS NULL, IS NOT NULL) taking type ANY,
then you wouldn't have to do any violence to the ScanKeys representation
to handle these operators as index quals. Rather than adding them to
pg_opclass for every btree opclass, I'd be inclined to special-case them
in the planner (they could be a case that special_indexable_operator
handles) --- with only two to deal with, that doesn't seem impractical.
Hm, probably only IS NULL need be indexable. We don't index != ...
regards, tom lane
