ST_OrderingEquals should not have strict on the definition

[robe]

I was talking with Vicky on pgRouting and she was working on revamping osm2pgrouting.

I asked ehr

Why are you using && with ST_OrderingEquals and she said "Cause it's super slow without it"

So I looked at the function and what do I see:

CREATE OR REPLACE FUNCTION st_orderingequals(
    geometrya geometry,
    geometryb geometry)
  RETURNS boolean AS
$$
	SELECT $1 ~= $2 AND _ST_OrderingEquals($1, $2)
$$
  LANGUAGE sql IMMUTABLE STRICT
  COST 100;

Hmm who put STRICT there — forcing this function to look opaque to the planner thereby preventing the index part from kicking in.

[robe]

Committed for postgis 2.1 branch at r13903

[robe]

Committed for postgis 2.2 at r13904