|
8 | 8 | * Portions Copyright (c) 1994, Regents of the University of California
|
9 | 9 | *
|
10 | 10 | * IDENTIFICATION
|
11 |
| - * $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsearch.c,v 1.108 2006/12/23 00:43:09 tgl Exp $ |
| 11 | + * $PostgreSQL: pgsql/src/backend/access/nbtree/nbtsearch.c,v 1.109 2006/12/28 23:16:39 tgl Exp $ |
12 | 12 | *
|
13 | 13 | *-------------------------------------------------------------------------
|
14 | 14 | */
|
@@ -476,16 +476,16 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
|
476 | 476 | * attributes to its right, because it would break our simplistic notion
|
477 | 477 | * of what initial positioning strategy to use.
|
478 | 478 | *
|
479 |
| - * When the scan keys include non-default operators, _bt_preprocess_keys |
| 479 | + * When the scan keys include cross-type operators, _bt_preprocess_keys |
480 | 480 | * may not be able to eliminate redundant keys; in such cases we will
|
481 | 481 | * arbitrarily pick a usable one for each attribute. This is correct
|
482 | 482 | * but possibly not optimal behavior. (For example, with keys like
|
483 | 483 | * "x >= 4 AND x >= 5" we would elect to scan starting at x=4 when
|
484 |
| - * x=5 would be more efficient.) Since the situation only arises in |
485 |
| - * hokily-worded queries, live with it. |
| 484 | + * x=5 would be more efficient.) Since the situation only arises given |
| 485 | + * a poorly-worded query plus an incomplete opfamily, live with it. |
486 | 486 | *
|
487 | 487 | * When both equality and inequality keys appear for a single attribute
|
488 |
| - * (again, only possible when non-default operators appear), we *must* |
| 488 | + * (again, only possible when cross-type operators appear), we *must* |
489 | 489 | * select one of the equality keys for the starting point, because
|
490 | 490 | * _bt_checkkeys() will stop the scan as soon as an equality qual fails.
|
491 | 491 | * For example, if we have keys like "x >= 4 AND x = 10" and we elect to
|
@@ -658,11 +658,15 @@ _bt_first(IndexScanDesc scan, ScanDirection dir)
|
658 | 658 | * to an insertion scan key by replacing the sk_func with the
|
659 | 659 | * appropriate btree comparison function.
|
660 | 660 | *
|
661 |
| - * If scankey operator is of the default type for the index, we |
662 |
| - * can use the cached comparison function; otherwise gotta look it |
663 |
| - * up in the catalogs. Also, we support the convention that |
664 |
| - * sk_subtype == 0 means the default type; this is a hack to |
665 |
| - * simplify life for ScanKeyInit(). |
| 661 | + * If scankey operator is not a cross-type comparison, we can use |
| 662 | + * the cached comparison function; otherwise gotta look it up in |
| 663 | + * the catalogs. (That can't lead to infinite recursion, since no |
| 664 | + * indexscan initiated by syscache lookup will use cross-data-type |
| 665 | + * operators.) |
| 666 | + * |
| 667 | + * We support the convention that sk_subtype == InvalidOid means |
| 668 | + * the opclass input type; this is a hack to simplify life for |
| 669 | + * ScanKeyInit(). |
666 | 670 | */
|
667 | 671 | if (cur->sk_subtype == rel->rd_opcintype[i] ||
|
668 | 672 | cur->sk_subtype == InvalidOid)
|
|
0 commit comments