impose a strict ordering on keys, lesser to greater. Since
Postgres allows the user to define operators,
Postgres cannot look at the name of an operator
- (eg, ">" or "<") and tell what kind of comparison it is. In fact,
+ (eg, ">" or "<") and tell what kind of comparison it is. In fact,
some access methods don't impose any ordering at all. For example,
R-trees express a rectangle-containment relationship,
whereas a hashed data structure expresses only bitwise similarity based
needs some consistent way of taking a qualification in your query,
looking at the operator and then deciding if a usable index exists. This
implies that
Postgres needs to know, for
- example, that the "<=" and ">" operators partition a
+ example, that the "<=" and ">" operators partition a
uses strategies to express these relationships between
operators and the way they can be used to scan indices.
Strictly speaking, this routine can return a negative
- number (< 0), 0, or a non-zero positive number (> 0).
+ number (< 0), 0, or a non-zero positive number (> 0).
FROM pg_am am, pg_opclass opcl, complex_ops_tmp c
WHERE amname = 'btree' AND
opcname = 'complex_abs_ops' AND
- c.oprname = '<';
+ c.oprname = '<';
Now do this for the other operators substituting for the "1" in the
- third line above and the "<" in the last line. Note the order:
+ third line above and the "<" in the last line. Note the order:
"less than" is 1, "less than or equal" is 2, "equal" is 3, "greater
than or equal" is 4, and "greater than" is 5.