sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-05-28 00:03:23 -04:00
Code Issues Projects Releases Wiki Activity

Oops, missed some < and > that need to be &lt; and &gt; ...

Browse Source
This commit is contained in:
Tom Lane 2000-03-28 02:59:55 +00:00
parent 0fb864f166
commit 9dc12ef54f
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,5 +1,5 @@
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.9 2000/03/28 02:53:02 tgl Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/xindex.sgml,v 1.10 2000/03/28 02:59:55 tgl Exp $
Postgres documentation Postgres documentation
--> -->
@ -107,7 +107,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
impose a strict ordering on keys, lesser to greater. Since impose a strict ordering on keys, lesser to greater. Since
<productname>Postgres</productname> allows the user to define operators, <productname>Postgres</productname> allows the user to define operators,
<productname>Postgres</productname> cannot look at the name of an operator <productname>Postgres</productname> cannot look at the name of an operator
(eg, ">" or "<") and tell what kind of comparison it is. In fact, (eg, "&gt;" or "&lt;") and tell what kind of comparison it is. In fact,
some access methods don't impose any ordering at all. For example, some access methods don't impose any ordering at all. For example,
<acronym>R-tree</acronym>s express a rectangle-containment relationship, <acronym>R-tree</acronym>s express a rectangle-containment relationship,
whereas a hashed data structure expresses only bitwise similarity based whereas a hashed data structure expresses only bitwise similarity based
@ -115,7 +115,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
needs some consistent way of taking a qualification in your query, needs some consistent way of taking a qualification in your query,
looking at the operator and then deciding if a usable index exists. This looking at the operator and then deciding if a usable index exists. This
implies that <productname>Postgres</productname> needs to know, for implies that <productname>Postgres</productname> needs to know, for
example, that the "<=" and ">" operators partition a example, that the "&lt;=" and "&gt;" operators partition a
<acronym>B-tree</acronym>. <productname>Postgres</productname> <acronym>B-tree</acronym>. <productname>Postgres</productname>
uses strategies to express these relationships between uses strategies to express these relationships between
operators and the way they can be used to scan indices. operators and the way they can be used to scan indices.
@ -203,7 +203,7 @@ SELECT oid FROM pg_am WHERE amname = 'btree';
<note> <note>
<para> <para>
Strictly speaking, this routine can return a negative Strictly speaking, this routine can return a negative
number (< 0), 0, or a non-zero positive number (> 0). number (&lt; 0), 0, or a non-zero positive number (&gt; 0).
</para> </para>
</note> </note>
</para> </para>
@ -427,11 +427,11 @@ CREATE OPERATOR = (
FROM pg_am am, pg_opclass opcl, complex_ops_tmp c FROM pg_am am, pg_opclass opcl, complex_ops_tmp c
WHERE amname = 'btree' AND WHERE amname = 'btree' AND
opcname = 'complex_abs_ops' AND opcname = 'complex_abs_ops' AND
c.oprname = '<'; c.oprname = '&lt;';
</programlisting> </programlisting>
Now do this for the other operators substituting for the "1" in the Now do this for the other operators substituting for the "1" in the
third line above and the "<" in the last line. Note the order: third line above and the "&lt;" in the last line. Note the order:
"less than" is 1, "less than or equal" is 2, "equal" is 3, "greater "less than" is 1, "less than or equal" is 2, "equal" is 3, "greater
than or equal" is 4, and "greater than" is 5. than or equal" is 4, and "greater than" is 5.
</para> </para>