Finish repairing 6.5's problems with r-tree indexes: create appropriate

selectivity functions and make the r-tree operators use them.  The
estimation functions themselves are just stubs, unfortunately, but
perhaps someday someone will make them compute realistic estimates.
Change pg_am so that the optimizer can reliably tell the difference
between ordered and unordered indexes --- before it would think that
an r-tree index can be scanned in '<<' order, which is not right AFAIK.
Repair broken negator links for network_sup and related ops.
Initdb forced.  This might be my last initdb force for 7.0 ... hope so
anyway ...

2 files changed, 20 insertions, 2 deletions

diff --git a/src/test/regress/expected/create_index.out b/src/test/regress/expected/create_index.out
index 3b070452e4d..3e727517741 100644
--- a/src/test/regress/expected/create_index.out
+++ b/src/test/regress/expected/create_index.out
@@ -47,10 +47,22 @@ CREATE INDEX bt_f8_index ON bt_f8_heap USING btree (seqno float8_ops);
 -- 
 -- rtrees use a quadratic page-splitting algorithm that takes a
 -- really, really long time.  we don't test all rtree opclasses
--- in the regression test (we check them USING the sequoia 2000
+-- in the regression test (we check them using the sequoia 2000
 -- benchmark).
 --
 CREATE INDEX rect2ind ON fast_emp4000 USING rtree (home_base bigbox_ops);
+-- there's no easy way to check that this command actually is using
+-- the index, unfortunately.  (EXPLAIN would work, but its output
+-- changes too often for me to want to put an EXPLAIN in the test...)
+SELECT * FROM fast_emp4000
+    WHERE home_base @ '(200,200),(2000,1000)'::box
+    ORDER BY home_base USING <<;
+       home_base       
+-----------------------
+ (337,455),(240,359)
+ (1444,403),(1346,344)
+(2 rows)
+
 --
 -- HASH
 --
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index 00281765a30..2ebc7ef3c3a 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -70,11 +70,17 @@ CREATE INDEX bt_f8_index ON bt_f8_heap USING btree (seqno float8_ops);
 -- 
 -- rtrees use a quadratic page-splitting algorithm that takes a
 -- really, really long time.  we don't test all rtree opclasses
--- in the regression test (we check them USING the sequoia 2000
+-- in the regression test (we check them using the sequoia 2000
 -- benchmark).
 --
 CREATE INDEX rect2ind ON fast_emp4000 USING rtree (home_base bigbox_ops);
 
+-- there's no easy way to check that this command actually is using
+-- the index, unfortunately.  (EXPLAIN would work, but its output
+-- changes too often for me to want to put an EXPLAIN in the test...)
+SELECT * FROM fast_emp4000
+    WHERE home_base @ '(200,200),(2000,1000)'::box
+    ORDER BY home_base USING <<;
 
 --
 -- HASH