First cut at making useful selectivity estimates for range queries

(ie, WHERE x > lowbound AND x < highbound).  It's not very bright yet
but it does something useful.  Also, rename intltsel/intgtsel to
scalarltsel/scalargtsel to reflect usage better.  Extend convert_to_scalar
to do something a little bit useful with string data types.  Still need
to make it do something with date/time datatypes, but I'll wait for
Thomas's datetime unification dust to settle first.  Eventually the
routine ought not have any type-specific knowledge at all; it ought to
be calling a type-dependent routine found via a pg_type column; but
that's a task for another day.

doc/src/sgml/xindex.sgml

@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.6 2000/01/22 23:50:08 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.7 2000/01/24 07:16:49 tgl Exp $
 Postgres documentation
 -->
 
@@ -542,25 +542,25 @@ CREATE OPERATOR = (
             oprleft = (SELECT oid FROM pg_type WHERE typname = 'complex_abs');
     
     UPDATE pg_operator
-        SET oprrest = 'intltsel'::regproc, oprjoin = 'intltjoinsel'
+        SET oprrest = 'scalarltsel'::regproc, oprjoin = 'scalarltjoinsel'
         WHERE oprname = '<' AND 
             oprleft = oprright AND
             oprleft = (SELECT oid FROM pg_type WHERE typname = 'complex_abs');
     
     UPDATE pg_operator
-        SET oprrest = 'intltsel'::regproc, oprjoin = 'intltjoinsel'
+        SET oprrest = 'scalarltsel'::regproc, oprjoin = 'scalarltjoinsel'
         WHERE oprname = '<=' AND
             oprleft = oprright AND
             oprleft = (SELECT oid FROM pg_type WHERE typname = 'complex_abs');
     
     UPDATE pg_operator
-        SET oprrest = 'intgtsel'::regproc, oprjoin = 'intgtjoinsel'
+        SET oprrest = 'scalargtsel'::regproc, oprjoin = 'scalargtjoinsel'
         WHERE oprname = '>' AND
             oprleft = oprright AND
             oprleft = (SELECT oid FROM pg_type WHERE typname = 'complex_abs');
     
     UPDATE pg_operator
-        SET oprrest = 'intgtsel'::regproc, oprjoin = 'intgtjoinsel'
+        SET oprrest = 'scalargtsel'::regproc, oprjoin = 'scalargtjoinsel'
         WHERE oprname = '>=' AND
             oprleft = oprright AND
             oprleft = (SELECT oid FROM pg_type WHERE typname = 'complex_abs');</filename></filename>

doc/src/sgml/xoper.sgml

@@ -231,8 +231,8 @@ SELECT (a + b) AS c FROM test_complex;
    <ProgramListing>
 	eqsel		for =
 	neqsel		for &lt;&gt;
-	intltsel	for &lt; or &lt;=
-	intgtsel	for &gt; or &gt;=
+	scalarltsel	for &lt; or &lt;=
+	scalargtsel	for &gt; or &gt;=
    </ProgramListing>
     It might seem a little odd that these are the categories, but they
     make sense if you think about it.  '=' will typically accept only
@@ -254,6 +254,17 @@ SELECT (a + b) AS c FROM test_complex;
     matching operators (~, ~*, etc) use eqsel on the assumption that they'll
     usually only match a small fraction of the entries in a table.
    </para>
+
+   <para>
+    You can use scalarltsel and scalargtsel for comparisons on datatypes that
+    have some sensible means of being converted into numeric scalars for
+    range comparisons.  If possible, add the datatype to those understood
+    by the routine convert_to_scalar() in src/backend/utils/adt/selfuncs.c.
+    (Eventually, this routine should be replaced by per-datatype functions
+    identified through a column of the pg_type table; but that hasn't happened
+    yet.)  If you do not do this, things will still work, but the optimizer's
+    estimates won't be as good as they could be.
+   </para>
    </sect2>
 
    <sect2>
@@ -281,8 +292,8 @@ SELECT (a + b) AS c FROM test_complex;
      <ProgramListing>
 	eqjoinsel	for =
 	neqjoinsel	for &lt;&gt;
-	intltjoinsel	for &lt; or &lt;=
-	intgtjoinsel	for &gt; or &gt;=
+	scalarltjoinsel	for &lt; or &lt;=
+	scalargtjoinsel	for &gt; or &gt;=
     </ProgramListing>
     </para>
    </sect2>