rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix up typos. 

Move "query result" tables to left side of page (remove leading spaces).
This commit is contained in:
Thomas G. Lockhart 2000-06-14 13:10:48 +00:00
parent ff7b9f5541
commit ee7f92b76b
1 changed files with 281 additions and 272 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
doc/src/sgml/sql.sgml
View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/sql.sgml,v 1.9 2000/05/02 20:01:52 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/sql.sgml,v 1.10 2000/06/14 13:10:48 thomas Exp $
-->
<chapter id="sql">
@ -155,16 +155,18 @@ $Header: /cvsroot/pgsql/doc/src/sgml/sql.sgml,v 1.9 2000/05/02 20:01:52 thomas E
<example>
<title id="supplier-fig">The Suppliers and Parts Database</title>
<programlisting>
SUPPLIER SNO | SNAME | CITY SELLS SNO | PNO
-----+---------+-------- -----+-----
SUPPLIER: SELLS:
SNO | SNAME | CITY SNO | PNO
----+---------+-------- -----+-----
1 | Smith | London 1 | 1
2 | Jones | Paris 1 | 2
3 | Adams | Vienna 2 | 4
4 | Blake | Rome 3 | 1
3 | 3
4 | 2
PART PNO | PNAME | PRICE 4 | 3
-----+---------+--------- 4 | 4
PART: 4 | 3
PNO | PNAME | PRICE 4 | 4
----+---------+---------
1 | Screw | 10
2 | Nut | 8
3 | Bolt | 15
@ -474,7 +476,7 @@ attributes are taken from. We often write a relation scheme as
INTERSECT (&cap;): builds the set-theoretic intersection of two
tables. Given the tables <classname>R</classname> and
<classname>S</classname>,
<classname>R</classname> &cup; <classname>S</classname> is the
<classname>R</classname> &cap; <classname>S</classname> is the
set of tuples
that are in <classname>R</classname> and in
<classname>S</classname>.
@ -532,7 +534,8 @@ attributes are taken from. We often write a relation scheme as
Let the following two tables be given:
<programlisting>
R A | B | C S C | D | E
R: S:
A | B | C C | D | E
---+---+--- ---+---+---
1 | 2 | 3 3 | a | b
4 | 5 | 6 6 | c | d
@ -547,7 +550,8 @@ attributes are taken from. We often write a relation scheme as
get:
<programlisting>
R x S A | B | R.C | S.C | D | E
R x S:
A | B | R.C | S.C | D | E
---+---+-----+-----+---+---
1 | 2 | 3 | 3 | a | b
1 | 2 | 3 | 6 | c | d
@ -595,8 +599,9 @@ attributes are taken from. We often write a relation scheme as
C and D.
Then we define the division as:
R &divide; S = {t &mid; &forall; t<subscript>s</subscript> &isin; S
&exist; t<subscript>r</subscript> &isin; R
<programlisting>
R &divide; S = {t &mid; &forall; t<subscript>s</subscript> &isin; S &exist; t<subscript>r</subscript> &isin; R
</programlisting>
such that
t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>s</subscript>}
@ -614,7 +619,8 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
Given the following tables
<programlisting>
R A | B | C | D S C | D
R: S:
A | B | C | D C | D
---+---+---+--- ---+---
a | b | c | d c | d
a | b | e | f e | f
@ -720,7 +726,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<para>
The queries used in <acronym>TRC</acronym> are of the following
form:
<programlisting>
x(A) &mid; F(x)
</programlisting>
where <literal>x</literal> is a tuple variable
<classname>A</classname> is a set of attributes and <literal>F</literal> is a
@ -734,10 +743,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
using <acronym>TRC</acronym> we formulate the following query:
<programlisting>
{x(SNAME) &mid; x &isin; SUPPLIER &and; \nonumber
&exist; y &isin; SELLS &exist; z &isin; PART (y(SNO)=x(SNO) &and; \nonumber
z(PNO)=y(PNO) &and; \nonumber
z(PNAME)='Screw')} \nonumber
{x(SNAME) &mid; x &isin; SUPPLIER &and;
&exist; y &isin; SELLS &exist; z &isin; PART (y(SNO)=x(SNO) &and;
z(PNO)=y(PNO) &and;
z(PNAME)='Screw')}
</programlisting>
</para>
@ -806,7 +815,9 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
to involve
arithmetic operations as well as comparisons, e.g.
<programlisting>
A &lt; B + 3.
</programlisting>
Note
that + or other arithmetic operators appear neither in relational
@ -1348,8 +1359,9 @@ gives the result:
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
The only tuple returned by both parts of the query is the one having $SNO=2$.
</programlisting>
The only tuple returned by both parts of the query is the one having $SNO=2$.
</para>
<para>
@ -1463,7 +1475,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<replaceable class="parameter">q</replaceable>
of them right to the decimal point.
(15 &ge; <replaceable class="parameter">p</replaceable> &ge; <replaceable class="parameter">q</replaceable>q &ge; 0).
(15 &ge; <replaceable class="parameter">p</replaceable> &ge; <replaceable class="parameter">q</replaceable> &ge; 0).
If <replaceable class="parameter">q</replaceable>
is omitted it is assumed to be 0.
@ -1528,8 +1540,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
we use the following statement:
<programlisting>
CREATE INDEX I
ON SUPPLIER (SNAME);
CREATE INDEX I ON SUPPLIER (SNAME);
</programlisting>
</para>
@ -1612,8 +1623,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
if it were another base table:
<programlisting>
SELECT *
FROM London_Suppliers
SELECT * FROM London_Suppliers
WHERE P.PNAME = 'Screw';
</programlisting>
@ -1691,8 +1701,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<programlisting>
INSERT INTO <replaceable class="parameter">table_name</replaceable> (<replaceable class="parameter">name_of_attr_1</replaceable>
[, <replaceable class="parameter">name_of_attr_2</replaceable> [,...]])
VALUES (<replaceable class="parameter">val_attr_1</replaceable>
[, <replaceable class="parameter">val_attr_2</replaceable> [, ...]]);
VALUES (<replaceable class="parameter">val_attr_1</replaceable> [, <replaceable class="parameter">val_attr_2</replaceable> [, ...]]);
</programlisting>
</para>