mirror of
https://github.com/postgres/postgres.git
synced 2025-11-09 06:21:09 +03:00
Use PostgreSQL consistantly throughout docs. Before, usage was split evenly
between Postgres and PostgreSQL.
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
<!--
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.21 2001/09/13 15:55:24 petere Exp $
|
||||
Postgres documentation
|
||||
$Header: /cvsroot/pgsql/doc/src/sgml/ref/create_operator.sgml,v 1.22 2001/12/08 03:24:34 thomas Exp $
|
||||
PostgreSQL documentation
|
||||
-->
|
||||
|
||||
<refentry id="SQL-CREATEOPERATOR">
|
||||
@@ -205,7 +205,7 @@ CREATE
|
||||
</literallayout>
|
||||
For example, <literal>@-</literal> is an allowed operator name,
|
||||
but <literal>*-</literal> is not.
|
||||
This restriction allows <productname>Postgres</productname> to
|
||||
This restriction allows <productname>PostgreSQL</productname> to
|
||||
parse SQL-compliant queries without requiring spaces between tokens.
|
||||
</para>
|
||||
</listitem>
|
||||
@@ -218,7 +218,7 @@ CREATE
|
||||
For example, if you have defined a left-unary operator named <literal>@</literal>,
|
||||
you cannot write <literal>X*@Y</literal>; you must write
|
||||
<literal>X* @Y</literal> to ensure that
|
||||
<productname>Postgres</productname> reads it as two operator names
|
||||
<productname>PostgreSQL</productname> reads it as two operator names
|
||||
not one.
|
||||
</para>
|
||||
</note>
|
||||
@@ -242,7 +242,7 @@ CREATE
|
||||
</para>
|
||||
<para>
|
||||
The commutator operator should be identified if one exists,
|
||||
so that <productname>Postgres</productname> can
|
||||
so that <productname>PostgreSQL</productname> can
|
||||
reverse the order of the operands if it wishes.
|
||||
For example, the operator area-less-than, <<<,
|
||||
would probably have a commutator
|
||||
@@ -280,7 +280,7 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
</para>
|
||||
<para>
|
||||
If a commutator operator name is supplied,
|
||||
<productname>Postgres</productname>
|
||||
<productname>PostgreSQL</productname>
|
||||
searches for it in the catalog. If it is found and it
|
||||
does not yet have a commutator itself, then the commutator's
|
||||
entry is updated to have the newly created operator as its
|
||||
@@ -290,17 +290,18 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
operator should be defined without a commutator or negator
|
||||
(as appropriate). When the second operator is defined,
|
||||
name the first as the commutator or negator. The first
|
||||
will be updated as a side effect. (As of Postgres 6.5,
|
||||
will be updated as a side effect. (As of
|
||||
<application>PostgreSQL</application> <literal>6.5</literal>,
|
||||
it also works to just have both operators refer to each other.)
|
||||
</para>
|
||||
<para>
|
||||
The HASHES, SORT1, and SORT2 options are present to support the
|
||||
query optimizer in performing joins.
|
||||
<productname>Postgres</productname> can always
|
||||
<productname>PostgreSQL</productname> can always
|
||||
evaluate a join (i.e., processing a clause with two tuple
|
||||
variables separated by an operator that returns a boolean)
|
||||
by iterative substitution [WONG76].
|
||||
In addition, <productname>Postgres</productname>
|
||||
In addition, <productname>PostgreSQL</productname>
|
||||
can use a hash-join algorithm along
|
||||
the lines of [SHAP86]; however, it must know whether this
|
||||
strategy is applicable. The current hash-join algorithm
|
||||
@@ -321,7 +322,7 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
</para>
|
||||
<para>
|
||||
If other join strategies are found to be practical,
|
||||
<productname>Postgres</productname>
|
||||
<productname>PostgreSQL</productname>
|
||||
will change the optimizer and run-time system to use
|
||||
them and will require additional specification when an
|
||||
operator is defined. Fortunately, the research community
|
||||
@@ -336,7 +337,7 @@ MYBOXES.description !== box '((0,0), (1,1))'
|
||||
MYBOXES.description <<< box '((0,0), (1,1))'
|
||||
</programlisting>
|
||||
is present in the qualification,
|
||||
then <productname>Postgres</productname> may have to
|
||||
then <productname>PostgreSQL</productname> may have to
|
||||
estimate the fraction of the instances in MYBOXES that
|
||||
satisfy the clause. The function
|
||||
<replaceable class="parameter">res_proc</replaceable>
|
||||
@@ -364,7 +365,7 @@ my_procedure_1 (MYBOXES.description, box '((0,0), (1,1))')
|
||||
<programlisting>
|
||||
MYBOXES.description === box '((0,0), (1,1))'
|
||||
</programlisting>
|
||||
is that <productname>Postgres</productname>
|
||||
is that <productname>PostgreSQL</productname>
|
||||
attempts to optimize operators and can
|
||||
decide to use an index to restrict the search space when
|
||||
operators are involved. However, there is no attempt to
|
||||
@@ -428,7 +429,7 @@ CREATE OPERATOR === (
|
||||
|
||||
<para>
|
||||
<command>CREATE OPERATOR</command>
|
||||
is a <productname>Postgres</productname> extension.
|
||||
is a <productname>PostgreSQL</productname> extension.
|
||||
There is no <command>CREATE OPERATOR</command>
|
||||
statement in <acronym>SQL92</acronym>.
|
||||
</para>
|
||||
|
||||
Reference in New Issue
Block a user