Restructure operator classes to allow improved handling of cross-data-type

cases.  Operator classes now exist within "operator families".  While most
families are equivalent to a single class, related classes can be grouped
into one family to represent the fact that they are semantically compatible.
Cross-type operators are now naturally adjunct parts of a family, without
having to wedge them into a particular opclass as we had done originally.

This commit restructures the catalogs and cleans up enough of the fallout so
that everything still works at least as well as before, but most of the work
needed to actually improve the planner's behavior will come later.  Also,
there are not yet CREATE/DROP/ALTER OPERATOR FAMILY commands; the only way
to create a new family right now is to allow CREATE OPERATOR CLASS to make
one by default.  I owe some more documentation work, too.  But that can all
be done in smaller pieces once this infrastructure is in place.

src/backend/access/hash/hashfunc.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/hash/hashfunc.c,v 1.48 2006/10/04 00:29:48 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/hash/hashfunc.c,v 1.49 2006/12/23 00:43:08 tgl Exp $
  *
  * NOTES
  *	  These functions are stored in pg_amproc.	For each operator class
@@ -46,11 +46,11 @@ hashint8(PG_FUNCTION_ARGS)
 {
 	/*
 	 * The idea here is to produce a hash value compatible with the values
-	 * produced by hashint4 and hashint2 for logically equivalent inputs; this
-	 * is necessary if we ever hope to support cross-type hash joins across
-	 * these input types.  Since all three types are signed, we can xor the
-	 * high half of the int8 value if the sign is positive, or the complement
-	 * of the high half when the sign is negative.
+	 * produced by hashint4 and hashint2 for logically equal inputs; this is
+	 * necessary to support cross-type hash joins across these input types.
+	 * Since all three types are signed, we can xor the high half of the int8
+	 * value if the sign is positive, or the complement of the high half when
+	 * the sign is negative.
 	 */
 #ifndef INT64_IS_BUSTED
 	int64		val = PG_GETARG_INT64(0);
@@ -76,16 +76,26 @@ Datum
 hashfloat4(PG_FUNCTION_ARGS)
 {
 	float4		key = PG_GETARG_FLOAT4(0);
+	float8		key8;
 
 	/*
 	 * On IEEE-float machines, minus zero and zero have different bit patterns
 	 * but should compare as equal.  We must ensure that they have the same
-	 * hash value, which is most easily done this way:
+	 * hash value, which is most reliably done this way:
 	 */
 	if (key == (float4) 0)
 		PG_RETURN_UINT32(0);
 
-	return hash_any((unsigned char *) &key, sizeof(key));
+	/*
+	 * To support cross-type hashing of float8 and float4, we want to return
+	 * the same hash value hashfloat8 would produce for an equal float8 value.
+	 * So, widen the value to float8 and hash that.  (We must do this rather
+	 * than have hashfloat8 try to narrow its value to float4; that could
+	 * fail on overflow.)
+	 */
+	key8 = key;
+
+	return hash_any((unsigned char *) &key8, sizeof(key8));
 }
 
 Datum
@@ -96,7 +106,7 @@ hashfloat8(PG_FUNCTION_ARGS)
 	/*
 	 * On IEEE-float machines, minus zero and zero have different bit patterns
 	 * but should compare as equal.  We must ensure that they have the same
-	 * hash value, which is most easily done this way:
+	 * hash value, which is most reliably done this way:
 	 */
 	if (key == (float8) 0)
 		PG_RETURN_UINT32(0);

src/backend/access/index/indexam.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/index/indexam.c,v 1.95 2006/10/04 00:29:48 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/index/indexam.c,v 1.96 2006/12/23 00:43:08 tgl Exp $
  *
  * INTERFACE ROUTINES
  *		index_open		- open an index relation by relation OID
@@ -608,17 +608,27 @@ index_vacuum_cleanup(IndexVacuumInfo *info,
 /* ----------------
  *		index_getprocid
  *
- *		Some indexed access methods may require support routines that are
- *		not in the operator class/operator model imposed by pg_am.	These
- *		access methods may store the OIDs of registered procedures they
- *		need in pg_amproc.	These registered procedure OIDs are ordered in
- *		a way that makes sense to the access method, and used only by the
- *		access method.	The general index code doesn't know anything about
- *		the routines involved; it just builds an ordered list of them for
+ *		Index access methods typically require support routines that are
+ *		not directly the implementation of any WHERE-clause query operator
+ *		and so cannot be kept in pg_amop.  Instead, such routines are kept
+ *		in pg_amproc.  These registered procedure OIDs are assigned numbers
+ *		according to a convention established by the access method.
+ *		The general index code doesn't know anything about the routines
+ *		involved; it just builds an ordered list of them for
  *		each attribute on which an index is defined.
  *
- *		This routine returns the requested procedure OID for a particular
- *		indexed attribute.
+ *		As of Postgres 8.3, support routines within an operator family
+ *		are further subdivided by the "left type" and "right type" of the
+ *		query operator(s) that they support.  The "default" functions for a
+ *		particular indexed attribute are those with both types equal to
+ *		the index opclass' opcintype (note that this is subtly different
+ *		from the indexed attribute's own type: it may be a binary-compatible
+ *		type instead).  Only the default functions are stored in relcache
+ *		entries --- access methods can use the syscache to look up non-default
+ *		functions.
+ *
+ *		This routine returns the requested default procedure OID for a
+ *		particular indexed attribute.
  * ----------------
  */
 RegProcedure
@@ -647,7 +657,8 @@ index_getprocid(Relation irel,
  *		index_getprocinfo
  *
  *		This routine allows index AMs to keep fmgr lookup info for
- *		support procs in the relcache.
+ *		support procs in the relcache.  As above, only the "default"
+ *		functions for any particular indexed attribute are cached.
  *
  * Note: the return value points into cached data that will be lost during
  * any relcache rebuild!  Therefore, either use the callinfo right away,

src/backend/access/nbtree/nbtsearch.c

@@ -8,7 +8,7 @@
  * Portions Copyright (c) 1994, Regents of the University of California
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsearch.c,v 1.107 2006/10/04 00:29:49 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsearch.c,v 1.108 2006/12/23 00:43:09 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -658,11 +658,14 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
 			 * to an insertion scan key by replacing the sk_func with the
 			 * appropriate btree comparison function.
 			 *
-			 * If scankey operator is of default subtype, we can use the
-			 * cached comparison function; otherwise gotta look it up in the
-			 * catalogs.
+			 * If scankey operator is of the default type for the index, we
+			 * can use the cached comparison function; otherwise gotta look it
+			 * up in the catalogs.  Also, we support the convention that
+			 * sk_subtype == 0 means the default type; this is a hack to
+			 * simplify life for ScanKeyInit().
 			 */
-			if (cur->sk_subtype == InvalidOid)
+			if (cur->sk_subtype == rel->rd_opcintype[i] ||
+				cur->sk_subtype == InvalidOid)
 			{
 				FmgrInfo   *procinfo;
 
@@ -671,7 +674,7 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
 											   cur->sk_flags,
 											   cur->sk_attno,
 											   InvalidStrategy,
-											   InvalidOid,
+											   cur->sk_subtype,
 											   procinfo,
 											   cur->sk_argument);
 			}
@@ -679,9 +682,14 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
 			{
 				RegProcedure cmp_proc;
 
-				cmp_proc = get_opclass_proc(rel->rd_indclass->values[i],
-											cur->sk_subtype,
-											BTORDER_PROC);
+				cmp_proc = get_opfamily_proc(rel->rd_opfamily[i],
+											 rel->rd_opcintype[i],
+											 cur->sk_subtype,
+											 BTORDER_PROC);
+				if (!RegProcedureIsValid(cmp_proc))
+					elog(ERROR, "missing support function %d(%u,%u) for attribute %d of index \"%s\"",
+						 BTORDER_PROC, rel->rd_opcintype[i], cur->sk_subtype,
+						 cur->sk_attno, RelationGetRelationName(rel));
 				ScanKeyEntryInitialize(scankeys + i,
 									   cur->sk_flags,
 									   cur->sk_attno,