[postgis-devel] ST_Equals, immutable strict

[Paragon Corporation]

>  Right, so the problem lies in "concluding the content of your function is
NON-STRICT", which fails in this case.

> Anarazel found that postgresql considers AND and OR inherently non-strict
[1], And that this is due to :

	SELECT NULL AND false; -- giving false

> But such construct really is only non-strict if any operand in the AND is
non-strict or is not using the argument.
In our case we have:

SELECT $1 && $2 AND _ST_Intersects($1,$2);
       ^^^^^^^^     ^^^^^^^^^^^^^^^^^^^^^

> They are both strict (the function is, the function associated with the
operator is), so for a NULL $1 or $2 the body would resolve in:

> 	NULL AND NULL

> I think either the planner should do a better job OR (better) let the
function definer signal inlinability with another switch (INLINE?)

Agree, but its technically not a bug.  Just laziness by design.  I suppose
we could bring it up as a feature.  I once brought up something like that to
Tom Lane regarding function costing (with OR that it doesn't), 
and
His argument was something to the effect "Yea I guess so" but takes more
effort for that extra smartness for little beneift in speed.

I suspect that would be the case here.  

Cause think about it as you said both && and _ST_Intersects are strict
anyway -- its going to be faster when you hit the NULLS even when you inline
it because the other functions will catch it.

Thanks,
Regina