aboutsummaryrefslogtreecommitdiff
path: root/doc/src/sgml/xoper.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'doc/src/sgml/xoper.sgml')
-rw-r--r--doc/src/sgml/xoper.sgml12
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