diff options
Diffstat (limited to 'doc/src/sgml/xoper.sgml')
-rw-r--r-- | doc/src/sgml/xoper.sgml | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/doc/src/sgml/xoper.sgml b/doc/src/sgml/xoper.sgml index f6394078669..e8e7c0da3f9 100644 --- a/doc/src/sgml/xoper.sgml +++ b/doc/src/sgml/xoper.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.38 2007/01/20 20:45:38 tgl Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/xoper.sgml,v 1.39 2007/01/31 20:56:20 momjian Exp $ --> <sect1 id="xoper"> <title>User-Defined Operators</title> @@ -230,7 +230,7 @@ column OP constant This assists the optimizer by giving it some idea of how many rows will be eliminated by <literal>WHERE</> clauses that have this form. (What happens if the constant is on - the left, you may be wondering? Well, that's one of the things that + the left, you might be wondering? Well, that's one of the things that <literal>COMMUTATOR</> is for...) </para> @@ -280,7 +280,7 @@ column OP constant <para> There are additional selectivity estimation functions designed for geometric operators in <filename>src/backend/utils/adt/geo_selfuncs.c</filename>: <function>areasel</function>, <function>positionsel</function>, - and <function>contsel</function>. At this writing these are just stubs, but you may want + and <function>contsel</function>. At this writing these are just stubs, but you might want to use them (or even better, improve them) anyway. </para> </sect2> @@ -354,7 +354,7 @@ table1.column1 OP table2.column2 <para> Care should be exercised when preparing a hash function, because there are machine-dependent ways in which it might fail to do the right thing. - For example, if your data type is a structure in which there may be + For example, if your data type is a structure in which there might be uninteresting pad bits, you can't simply pass the whole structure to <function>hash_any</>. (Unless you write your other operators and functions to ensure that the unused bits are always zero, which is the @@ -380,7 +380,7 @@ table1.column1 OP table2.column2 strict, the function must also be complete: that is, it should return true or false, never null, for any two nonnull inputs. If this rule is - not followed, hash-optimization of <literal>IN</> operations may + not followed, hash-optimization of <literal>IN</> operations might generate wrong results. (Specifically, <literal>IN</> might return false where the correct answer according to the standard would be null; or it might yield an error complaining that it wasn't prepared for a @@ -431,7 +431,7 @@ table1.column1 OP table2.column2 A merge-joinable operator must have a commutator (itself if the two operand data types are the same, or a related equality operator if they are different) that appears in the same operator family. - If this is not the case, planner errors may occur when the operator + If this is not the case, planner errors might occur when the operator is used. Also, it is a good idea (but not strictly required) for a btree operator family that supports multiple datatypes to provide equality operators for every combination of the datatypes; this |