database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-22 17:42:17 +03:00
Code Activity

Update documentation on may/can/might:

Browse Source 
Standard English uses "may", "can", and "might" in different ways:

        may - permission, "You may borrow my rake."

        can - ability, "I can lift that log."

        might - possibility, "It might rain today."

Unfortunately, in conversational English, their use is often mixed, as
in, "You may use this variable to do X", when in fact, "can" is a better
choice.  Similarly, "It may crash" is better stated, "It might crash".

Also update two error messages mentioned in the documenation to match.
This commit is contained in:
Bruce Momjian
2007-01-31 20:56:20 +00:00
parent 67a1ae9f05
commit a134ee3379
70 changed files with 729 additions and 731 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/src/sgml/xoper.sgml
View File

@@ -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