>
>
>
>
>>I remember looking into this a while ago. My solution to that problem was
>>that x =3D NULL is always NULL and so doesn't need to go through the scan
>>anyway (index or sequential). Once you've taken care of the x =3D NULL case
>>elsewhere, you can use the available state for x IS NULL.
>>
>>
>
>But how do you get from point A to point B? You need to represent both
>cases in ScanKeys further upstream than where that conclusion can be
>drawn (namely _bt_orderkeys()) --- or else do some very substantial
>restructuring work, which is exactly the point.
>
>
I think what he meant was that a = null is actually a CONSTANT (null)
and can be
reduced at the parsing/planning stage, so that the indexing code never
has to deal with such condition at all, and the only
way for it to ever see SK_NULL would be the case of 'is null'...
As for the hard-wired assumption that indexable operators are always
strict, it seems to me that it is already there -
_bt_checkkeys() always retruns false if it ever sees a null key. Doesn't
it mean that it assumes that all the operators it will ever see are strict?
Dima