Oleg Bartunov <oleg@sai.msu.su> writes:
> contrib/cube is just a bad example :-) In any case if you give an
> interface to developer it's his responsibility to be aware of possible
> errors. Developer has always a possibility to divide by zero.
> We could change contrib/cube to be null-safe.
My point is that as it stands, GIST is not honoring the defined
interface for nulls. AFAICT you are relying on the called opclass
routines to test for null pointers, which is not clean. (Among other
things, it means that you cannot work with pass-by-value datatypes.)
There has to be a separate isNull flag for each value.
contrib/cube very possibly is broken, but that doesn't mean that the
core GIST code isn't at fault too.
> DirectFunctionCallN are already interface to
> opclass support routines.
But the FunctionCallN routines do not allow passing or returning NULL.
That was a deliberate choice to preserve notational simplicity, because
most of the places where they needed to be used didn't have to worry
about NULLs. You do, so you can't use those routines.
>> The macro-issue is what you intend to
>> do with NULLs in the first place. I understand what btree does
>> with them, but what's the corresponding concept for GIST?
> if you mean first NULL keys in multikey GiST than just remove this tuple
> from index because it's informativeless. btw, what btree does ?
If you remove the tuple from the index then you're not storing NULLs.
You need to pick a rule that defines where null rows will get placed
in the index. For btree, the rule is "nulls sort after all non-nulls".
regards, tom lane