Very minor improvements in CREATE OPERATOR docs.

diff --git a/doc/src/sgml/ref/create_operator.sgml b/doc/src/sgml/ref/create_operator.sgml
index eda81ff..1e745a4 100644 (file)
--- a/doc/src/sgml/ref/create_operator.sgml
+++ b/doc/src/sgml/ref/create_operator.sgml
@@ -227,11 +227,11 @@ Operator that sorts the right-hand data type of this operator.
    (either  one or two).
   </para>
   <para>
-   The  commutator  operator  is present so that
-   <productname>Postgres</productname> can
+   The commutator operator should be identified if one exists,
+   so that <productname>Postgres</productname> can
    reverse the order of the operands if it wishes.
    For example, the operator area-less-than, &lt;&lt;&lt;,
-   would have a commutator
+   would probably have a commutator
    operator, area-greater-than, &gt;&gt;&gt;.
    Hence, the query optimizer could freely  convert:
    <programlisting>
@@ -243,14 +243,15 @@ Operator that sorts the right-hand data type of this operator.
   </para>
   <para>
    This  allows  the  execution code to always use the latter
-   representation and simplifies the  query  optimizer  some
-   what.
+   representation and simplifies the  query  optimizer  somewhat.
   </para>
   <para>
+   Similarly, if there is a negator operator then it should be
+   identified.
    Suppose  that  an
    operator,  area-equal, ===, exists, as well as an area not
    equal, !==.
-   The negator operator allows the query optimizer to convert
+   The negator link allows the query optimizer to simplify
    <programlisting>
     NOT MYBOXES.description === "0,0,1,1"::box
    </programlisting>
@@ -325,8 +326,8 @@ Operator that sorts the right-hand data type of this operator.
    satisfy  the clause.  The function
    <replaceable class="parameter">res_proc</replaceable>
    must be a registered function (meaning  it  is  already  defined  using
-   define function(l)) which accepts one argument of the correct
-   data type and returns a floating point  number.   The
+   CREATE FUNCTION) which accepts arguments of the correct
+   data types and returns a floating point  number.   The
    query  optimizer  simply  calls this function, passing the
    parameter "0,0,1,1" and multiplies the result by the relation
    size to get the desired expected number of instances.

diff --git a/src/man/create_operator.l b/src/man/create_operator.l
index 7fca24e..c1167ca 100644 (file)
--- a/src/man/create_operator.l
+++ b/src/man/create_operator.l
@@ -1,6 +1,6 @@
 .\" This is -*-nroff-*-
 .\" XXX standard disclaimer belongs here....
-.\" $Header: /cvsroot/pgsql/src/man/Attic/create_operator.l,v 1.8 1999/04/15 00:09:00 tgl Exp $
+.\" $Header: /cvsroot/pgsql/src/man/Attic/create_operator.l,v 1.9 1999/05/20 03:21:02 tgl Exp $
 .TH "CREATE OPERATOR" SQL 11/05/95 PostgreSQL PostgreSQL
 .SH NAME
 create operator - define a new user operator
@@ -88,9 +88,10 @@ and must have one or two arguments.
 .\" .(l
 .\" MYBOXES2.description A (\*(lq0,0,1,1\*(rq A MYBOXES.description).
 .\" .)l
-The commutator operator is present so that Postgres can reverse the order
-of the operands if it wishes.  For example, the operator
-area-less-than, >>>, would have a commutator operator,
+The commutator operator should be identified if one exists,
+so that Postgres can reverse the order of the operands if it wishes.
+For example, the operator
+area-less-than, >>>, would probably have a commutator operator,
 area-greater-than, <<<.  Hence, the query optimizer
 could freely convert:
 .nf
@@ -109,9 +110,10 @@ MYBOXES.description <<< "0,0,1,1"::box
 This allows the execution code to always use the latter representation
 and simplifies the query optimizer somewhat.
 .PP
+Similarly, if there is a negator operator then it should be identified.
 Suppose that an operator, area-equal, ===,
 exists, as well as an area not equal, !==.
-The negator operator allows the query optimizer to convert
+The negator link allows the query optimizer to simplify
 .nf
 
 .ce 1
@@ -182,7 +184,7 @@ fraction of the instances in MYBOXES that satisfy the clause.  The
 function res_proc must be a registered function (meaning it is already
 defined using
 .IR create_function(l))
-which accepts one argument of the correct data type and returns a
+which accepts arguments of the correct data types and returns a
 floating point number.  The query optimizer simply calls this
 function, passing the parameter "0,0,1,1"
 and multiplies the result by the relation size to get the desired