|
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 includenon-default operators, _bt_preprocess_keys |
| 479 | + * When the scan keys includecross-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 arisesin |
485 | | - *hokily-wordedqueries, live with it. |
| 484 | + * x=5 would be more efficient.) Since the situation only arisesgiven |
| 485 | + *a poorly-wordedquery 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 whennon-default operators appear), we *must* |
| 488 | + * (again, only possible whencross-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) |
|