aboutsummaryrefslogtreecommitdiff
path: root/src/include/nodes/relation.h
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2007-05-31 16:57:34 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2007-05-31 16:57:34 +0000
commit10f719af331b0248f532fb1eeee642f93ed981a9 (patch)
treecde09eb1585a3a2e7861517b68a0ac0859d99a09 /src/include/nodes/relation.h
parent7ce9b3683ea76233c33e550110c5a63ecd8add89 (diff)
downloadpostgresql-10f719af331b0248f532fb1eeee642f93ed981a9.tar.gz
postgresql-10f719af331b0248f532fb1eeee642f93ed981a9.zip
Change build_index_pathkeys() so that the expressions it builds to represent
index key columns always have the type expected by the index's associated operators, ie, we add RelabelType nodes when dealing with binary-compatible index opclasses. This is needed to get varchar indexes to play nicely with the new EquivalenceClass machinery, as per recent gripe from Josh Berkus that CVS HEAD was failing to match a varchar index column to a constant restriction in the query. It seems likely that this change will allow removal of a lot of ugly ad-hoc RelabelType-stripping that the planner has traditionally done while matching expressions to other expressions, but I'll worry about that some other day.
Diffstat (limited to 'src/include/nodes/relation.h')
-rw-r--r--src/include/nodes/relation.h12
1 files changed, 7 insertions, 5 deletions
diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index d6b13ca8e39..4a2f2649691 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -7,7 +7,7 @@
* Portions Copyright (c) 1996-2007, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
- * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.143 2007/05/22 23:23:57 tgl Exp $
+ * $PostgreSQL: pgsql/src/include/nodes/relation.h,v 1.144 2007/05/31 16:57:34 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -370,10 +370,11 @@ typedef struct RelOptInfo
* and indexes, but that created confusion without actually doing anything
* useful. So now we have a separate IndexOptInfo struct for indexes.
*
- * opfamily[], indexkeys[], fwdsortop[], revsortop[], and nulls_first[]
- * each have ncolumns entries. Note: for historical reasons, the
- * opfamily array has an extra entry that is always zero. Some code
- * scans until it sees a zero entry, rather than looking at ncolumns.
+ * opfamily[], indexkeys[], opcintype[], fwdsortop[], revsortop[],
+ * and nulls_first[] each have ncolumns entries.
+ * Note: for historical reasons, the opfamily array has an extra entry
+ * that is always zero. Some code scans until it sees a zero entry,
+ * rather than looking at ncolumns.
*
* Zeroes in the indexkeys[] array indicate index columns that are
* expressions; there is one element in indexprs for each such column.
@@ -402,6 +403,7 @@ typedef struct IndexOptInfo
int ncolumns; /* number of columns in index */
Oid *opfamily; /* OIDs of operator families for columns */
int *indexkeys; /* column numbers of index's keys, or 0 */
+ Oid *opcintype; /* OIDs of opclass declared input data types */
Oid *fwdsortop; /* OIDs of sort operators for each column */
Oid *revsortop; /* OIDs of sort operators for backward scan */
bool *nulls_first; /* do NULLs come first in the sort order? */