Dima Tkach <dmitry@openratings.com> writes:
> 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,
If the = operator is strict, yes it will be. But that just begs the
question.
> 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?
That assumption does currently exist in _bt_checkkeys() and some other
localized places. But it could possibly be removed from them --- or a
new index access method could be written that makes no such assumption.
If you propagate the assumption upwards into ScanKeys and the planner,
then it'll never be possible to get rid of it, not even with an entirely
new access method.
These sorts of considerations are why I said that I thought a non-kluge
solution was difficult. Yes, we could hack slash and burn our way to
a patch that works (most of the time anyway) in short order. Developing
something that doesn't cripple future progress is another story.
regards, tom lane