open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix markup to allow doc building.

Browse Source
REL7_0_PATCHES
Thomas G. Lockhart 26 years ago
parent 2d1433517e
commit 3a82b67b22
4 changed files with 671 additions and 670 deletions
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Show Stats Download Patch File Download Diff File
  1. 4
      doc/src/sgml/inherit.sgml
  2. 4
      doc/src/sgml/query.sgml
  3. 780
      doc/src/sgml/release.sgml
  4. 553
      doc/src/sgml/sql.sgml

4
doc/src/sgml/inherit.sgml
Unescape View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.7 2000/05/02 20:01:51 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/Attic/inherit.sgml,v 1.7.2.1 2000/06/14 13:18:59 thomas Exp $
-->
<chapter id="inherit">
@ -40,6 +40,7 @@ CREATE TABLE capitals (
The inheritance hierarchy is a actually a directed acyclic graph.
</para>
</note>
</para>
For example, the following query finds
all the cities that are situated at an attitude of 500ft or higher:
@ -87,6 +88,7 @@ SELECT c.name, c.altitude
<command>ALTER TABLE</command>.
</para>
</chapter>
<para>
<!-- Keep this comment at the end of the file
Local variables:

4
doc/src/sgml/query.sgml
Unescape View File

@ -1,5 +1,5 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.11 2000/04/11 05:39:06 thomas Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/query.sgml,v 1.11.2.1 2000/06/14 13:18:59 thomas Exp $
-->
<chapter id="query">
@ -154,7 +154,7 @@ INSERT INTO weather
</para>
<para>
You can also use the <command>COPY</command> command to perform load large
You can also use <command>COPY</command> to load large
amounts of data from flat (<acronym>ASCII</acronym>) files.
This is usually faster because the data is read (or written) as a
single atomic

780
doc/src/sgml/release.sgml
Unescape View File

@ -1,87 +1,83 @@
<!--
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.49.2.5 2000/06/05 10:59:16 momjian Exp $
$Header: /cvsroot/pgsql/doc/src/sgml/release.sgml,v 1.49.2.6 2000/06/14 13:18:59 thomas Exp $
-->
<chapter id="release">
<title>Release Notes</title>
<sect1>
<title>Release 7.0.2</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>2000-06-05</date>
</docinfo>
-->
<sect1>
<title>Release 7.0.2</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>2000-06-05</date>
</docinfo>
-->
<para>
2000-06-05
</para>
<para>
This is a repackaging of 7.0.1 with added documentation.
</para>
<para>
Release date 2000-06-05. This is a repackaging of 7.0.1 with added documentation.
</para>
<sect2>
<title>Migration to v7.0.2</title>
<sect2>
<title>Migration to v7.0.2</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
7.*.
</para>
</sect2>
<sect2>
<title>Changes</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
v7.*.
</para>
</sect2>
<para>
<programlisting>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Added documentation to tarball.
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 7.0.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>2000-06-01</date>
</docinfo>
-->
<sect1>
<title>Release 7.0.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>2000-06-01</date>
</docinfo>
-->
<para>
2000-06-01
</para>
<para>
This is basically a cleanup release for 7.0.
</para>
<para>
Release date 2000-06-01.
This is a cleanup release for 7.0.
</para>
<sect2>
<title>Migration to v7.0.1</title>
<sect2>
<title>Migration to v7.0.1</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
v7.0.
</para>
</sect2>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
7.0.
</para>
</sect2>
<sect2>
<title>Changes</title>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Fix many CLUSTER failures (Tom)
Allow ALTER TABLE RENAME works on indexes (Tom)
Fix plpgsql to handle datetime->timestamp and timespan->interval (Bruce)
@ -106,11 +102,10 @@ Fix too long syslog message (Tatsuo)
Fix problem with quoted indexes that are too long (Tom)
JDBC ResultSet.getTimestamp() fix (Gregory Krasnow & Floyd Marinescu)
ecpg changes (Michael)
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 7.0</title>
@ -126,9 +121,7 @@ ecpg changes (Michael)
</docinfo>
-->
<para>
2000-05-08
</para>
<para>
Released 2000-05-08.
This release contains improvements in many areas, demonstrating
the continued growth of <productname>PostgreSQL</productname>.
There are more improvements and fixes in 7.0 than in any previous
@ -287,6 +280,8 @@ Ack! This isn't yet in the code?? - thomas 2000-04-30
</sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Bug Fixes
@ -611,87 +606,84 @@ New multibyte encodings
</sect2>
</sect1>
<sect1>
<title>Release 6.5.3</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-10-13</date>
</docinfo>
-->
<sect1>
<title>Release 6.5.3</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-10-13</date>
</docinfo>
-->
<para>
1999-10-13
</para>
<para>
This is basically a cleanup release for 6.5.2. We have added a new
pgaccess that was missing in 6.5.2, and installed an NT-specific fix.
</para>
<para>
Released 1999-10-13.
This is basically a cleanup release for 6.5.2. We have added a new
pgaccess that was missing in 6.5.2, and installed an NT-specific fix.
</para>
<sect2>
<title>Migration to v6.5.3</title>
<sect2>
<title>Migration to v6.5.3</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.*.
</para>
</sect2>
<sect2>
<title>Changes</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.*.
</para>
</sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Updated version of pgaccess 0.98
NT-specific patch
Fix dumping rules on inherited tables
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.5.2</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-09-15</date>
</docinfo>
-->
<sect1>
<title>Release 6.5.2</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-09-15</date>
</docinfo>
-->
<para>
1999-09-15
</para>
<para>
This is basically a cleanup release for 6.5.1. We have fixed a variety of
problems reported by 6.5.1 users.
</para>
<para>
Released 1999-09-15.
This is basically a cleanup release for 6.5.1. We have fixed a variety of
problems reported by 6.5.1 users.
</para>
<sect2>
<title>Migration to v6.5.2</title>
<sect2>
<title>Migration to v6.5.2</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.*.
</para>
</sect2>
<sect2>
<title>Changes</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.*.
</para>
</sect2>
<para>
<programlisting>
<sect2>
<title>Changes</title>
<para>
<programlisting>
subselect+CASE fixes(Tom)
Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren Sefcik)
Fixes for CASE in WHERE join clauses(Tom)
@ -716,48 +708,47 @@ Repair logic error in LIKE: should not return LIKE_ABORT
when reach end of pattern before end of text(Tom)
Repair incorrect cleanup of heap memory allocation during transaction abort(Tom)
Updated version of pgaccess 0.98
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.5.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-07-15</date>
</docinfo>
-->
<sect1>
<title>Release 6.5.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-07-15</date>
</docinfo>
-->
<para>
1999-07-15
</para>
<para>
This is basically a cleanup release for 6.5. We have fixed a variety of
problems reported by 6.5 users.
</para>
<para>
Released 1999-07-15.
</para>
<para>
This is basically a cleanup release for 6.5. We have fixed a variety of
problems reported by 6.5 users.
</para>
<sect2>
<title>Migration to v6.5.1</title>
<sect2>
<title>Migration to v6.5.1</title>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.
</para>
</sect2>
<para>
A dump/restore is <emphasis>not</emphasis> required for those running
6.5.
</para>
</sect2>
<sect2>
<title>Changes</title>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Add NT README file
Portability fixes for linux_ppc, Irix, linux_alpha, OpenBSD, alpha
Remove QUERY_LIMIT, use SELECT...LIMIT
@ -781,30 +772,27 @@ Shared library dependencies fixed (Tom)
Fixed glitches affecting GROUP BY in subselects(Tom)
Fix some compiler warnings (Tomoaki Nishiyama)
Add Win1250 (Czech) support (Pavel Behal)
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.5</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-06-09</date>
</docinfo>
-->
<sect1>
<title>Release 6.5</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1999-06-09</date>
</docinfo>
-->
<para>
1999-06-09
</para>
<para>
Released 1999-06-09.
This release marks a major step in the development team's mastery of the source
code we inherited from Berkeley. You will see we are now easily adding
major features, thanks to the increasing size and experience of our
@ -1023,6 +1011,8 @@ Add Win1250 (Czech) support (Pavel Behal)
</sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Bug Fixes
@ -1412,10 +1402,12 @@ is required for those wishing to migrate data from any
previous release of <productname>Postgres</productname>.
</para>
</sect2>
<sect2>
<para>
<programlisting>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Bug Fixes
---------
Fix for a tiny memory leak in PQsetdb/PQfinish(Bryan)
@ -1664,12 +1656,11 @@ For upgrades from pre-v6.3 installations,
refer to the installation and migration instructions for v6.3.
</para>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Changes
-------
<para>
<programlisting>
Configure detection improvements for tcl/tk(Brook Milligan, Alvin)
Manual page improvements(Bruce)
BETWEEN and LIKE fix(Thomas)
@ -1688,29 +1679,28 @@ libreadline cleanup(Erwan MAS)
Remove DISTDIR(Bruce)
Makefile dependency cleanup(Jeroen van Vianen)
ASSERT fixes(Bruce)
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.3.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1998-03-23</date>
</docinfo>
-->
</programlisting>
</para>
</sect2>
</sect1>
<para>
1998-03-23
</para>
<para>
Summary:
<sect1>
<title>Release 6.3.1</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1998-03-23</date>
</docinfo>
-->
<para>
Released 1998-03-23.
Summary:
<itemizedlist>
<listitem>
@ -1750,12 +1740,11 @@ For upgrades from pre-v6.3 installations,
refer to the installation and migration instructions for v6.3.
</para>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Changes
-------
<para>
<programlisting>
ecpg cleanup/fixes, now version 1.1(Michael Meskes)
pg_user cleanup(Bruce)
large object fix for pg_dump and tclsh (alvin)
@ -1783,59 +1772,58 @@ Fix Alpha port(Dwayne Bailey)
Fix for text arrays containing quotes(Doug Gibson)
Solaris compile fix(Albert Chin-A-Young)
Better identify tcl and tk libs and includes(Bruce)
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.3</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1998-03-01</date>
</docinfo>
-->
</programlisting>
</para>
</sect2>
</sect1>
<para>
1998-03-01
</para>
<para>
There are <emphasis>many</emphasis> new features and improvements in this release.
Here is a brief, incomplete summary:
<sect1>
<title>Release 6.3</title>
<!--
<docinfo>
<authorgroup>
<author>
<firstname>Bruce</firstname>
<surname>Momjian</surname>
</author>
</authorgroup>
<date>1998-03-01</date>
</docinfo>
-->
<itemizedlist>
<listitem>
<para>
Many new SQL features, including
full <acronym>SQL92</acronym> subselect capability
(everything is here but target-list subselects).
</para>
</listitem>
<para>
Released 1998-03-01.
There are <emphasis>many</emphasis> new features and improvements in this release.
Here is a brief, incomplete summary:
<listitem>
<para>
Support for client-side environment variables to specify time zone and date style.
</para>
</listitem>
<itemizedlist>
<listitem>
<para>
Many new SQL features, including
full <acronym>SQL92</acronym> subselect capability
(everything is here but target-list subselects).
</para>
</listitem>
<listitem>
<para>
Socket interface for client/server connection. This is the default now
so you may need to start <application>postmaster</application> with the
<option>-i</option> flag.
</para>
</listitem>
<listitem>
<para>
Support for client-side environment variables to specify time zone and date style.
</para>
</listitem>
<listitem>
<para>
Better password authorization mechanisms. Default table permissions have changed.
</para>
</listitem>
<listitem>
<para>
Socket interface for client/server connection. This is the default now
so you may need to start <application>postmaster</application> with the
<option>-i</option> flag.
</para>
</listitem>
<listitem>
<para>
Better password authorization mechanisms. Default table permissions have changed.
</para>
</listitem>
<listitem>
<para>
@ -1843,101 +1831,101 @@ Better password authorization mechanisms. Default table permissions have changed
has been removed. Performance has been improved.
</para>
</listitem>
</itemizedlist>
</para>
</itemizedlist>
</para>
<note>
<para>
Bruce Momjian wrote the following notes to introduce the new release.
</para>
</note>
<note>
<para>
Bruce Momjian wrote the following notes to introduce the new release.
</para>
</note>
<para>
There are some general 6.3 issues that I want to mention. These are
only the big items that can not be described in one sentence. A review
of the detailed changes list is still needed.
</para>
<para>
First, we now have subselects. Now that we have them, I would like to
mention that without subselects, SQL is a very limited language.
Subselects are a major feature, and you should review your code for
places where subselects provide a better solution for your queries. I
think you will find that there are more uses for subselects than you may
think. Vadim has put us on the big SQL map with subselects, and fully
functional ones too. The only thing you can't do with subselects is to
use them in the target list.
</para>
<para>
Second, 6.3 uses unix domain sockets rather than TCP/IP by default. To
enable connections from other machines, you have to use the new
postmaster -i option, and of course edit pg_hba.conf. Also, for this
reason, the format of pg_hba.conf has changed.
</para>
<para>
Third, char() fields will now allow faster access than varchar() or
text. Specifically, the text and varchar() have a penalty for access to
any columns after the first column of this type. char() used to also
have this access penalty, but it no longer does. This may suggest that
you redesign some of your tables, especially if you have short character
columns that you have defined as varchar() or text. This and other
changes make 6.3 even faster than earlier releases.
</para>
<para>
We now have passwords definable independent of any Unix file. There are
new SQL USER commands. See the pg_hba.conf manual page for more
information. There is a new table, pg_shadow, which is used to store
user information and user passwords, and it by default only SELECT-able
by the postgres super-user. pg_user is now a view of pg_shadow, and is
SELECT-able by PUBLIC. You should keep using pg_user in your
application without changes.
</para>
<para>
User-created tables now no longer have SELECT permission to PUBLIC by
default. This was done because the ANSI standard requires it. You can
of course GRANT any permissions you want after the table is created.
System tables continue to be SELECT-able by PUBLIC.
</para>
<para>
We also have real deadlock detection code. No more sixty-second
timeouts. And the new locking code implements a FIFO better, so there
should be less resource starvation during heavy use.
</para>
<para>
Many complaints have been made about inadequate documenation in previous
releases. Thomas has put much effort into many new manuals for this
release. Check out the doc/ directory.
</para>
<para>
For performance reasons, time travel is gone, but can be implemented
using triggers (see pgsql/contrib/spi/README). Please check out the new
\d command for types, operators, etc. Also, views have their own
permissions now, not based on the underlying tables, so permissions on
them have to be set separately. Check /pgsql/interfaces for some new
ways to talk to <productname>Postgres</productname>.
</para>
<para>
This is the first release that really required an explanation for
existing users. In many ways, this was necessary because the new
release removes many limitations, and the work-arounds people were using
are no longer needed.
</para>
<para>
There are some general 6.3 issues that I want to mention. These are
only the big items that can not be described in one sentence. A review
of the detailed changes list is still needed.
</para>
<para>
First, we now have subselects. Now that we have them, I would like to
mention that without subselects, SQL is a very limited language.
Subselects are a major feature, and you should review your code for
places where subselects provide a better solution for your queries. I
think you will find that there are more uses for subselects than you may
think. Vadim has put us on the big SQL map with subselects, and fully
functional ones too. The only thing you can't do with subselects is to
use them in the target list.
</para>
<para>
Second, 6.3 uses unix domain sockets rather than TCP/IP by default. To
enable connections from other machines, you have to use the new
postmaster -i option, and of course edit pg_hba.conf. Also, for this
reason, the format of pg_hba.conf has changed.
</para>
<para>
Third, char() fields will now allow faster access than varchar() or
text. Specifically, the text and varchar() have a penalty for access to
any columns after the first column of this type. char() used to also
have this access penalty, but it no longer does. This may suggest that
you redesign some of your tables, especially if you have short character
columns that you have defined as varchar() or text. This and other
changes make 6.3 even faster than earlier releases.
</para>
<para>
We now have passwords definable independent of any Unix file. There are
new SQL USER commands. See the pg_hba.conf manual page for more
information. There is a new table, pg_shadow, which is used to store
user information and user passwords, and it by default only SELECT-able
by the postgres super-user. pg_user is now a view of pg_shadow, and is
SELECT-able by PUBLIC. You should keep using pg_user in your
application without changes.
</para>
<para>
User-created tables now no longer have SELECT permission to PUBLIC by
default. This was done because the ANSI standard requires it. You can
of course GRANT any permissions you want after the table is created.
System tables continue to be SELECT-able by PUBLIC.
</para>
<para>
We also have real deadlock detection code. No more sixty-second
timeouts. And the new locking code implements a FIFO better, so there
should be less resource starvation during heavy use.
</para>
<para>
Many complaints have been made about inadequate documenation in previous
releases. Thomas has put much effort into many new manuals for this
release. Check out the doc/ directory.
</para>
<para>
For performance reasons, time travel is gone, but can be implemented
using triggers (see pgsql/contrib/spi/README). Please check out the new
\d command for types, operators, etc. Also, views have their own
permissions now, not based on the underlying tables, so permissions on
them have to be set separately. Check /pgsql/interfaces for some new
ways to talk to <productname>Postgres</productname>.
</para>
<para>
This is the first release that really required an explanation for
existing users. In many ways, this was necessary because the new
release removes many limitations, and the work-arounds people were using
are no longer needed.
</para>
<sect2>
<title>Migration to v6.3</title>
<sect2>
<title>Migration to v6.3</title>
<para>
A dump/restore using <application>pg_dump</application>
or <application>pg_dumpall</application>
is required for those wishing to migrate data from any
previous release of <productname>Postgres</productname>.
</para>
</sect2>
<para>
A dump/restore using <application>pg_dump</application>
or <application>pg_dumpall</application>
is required for those wishing to migrate data from any
previous release of <productname>Postgres</productname>.
</para>
</sect2>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Bug Fixes
---------
Fix binary cursors broken by MOVE implementation(Vadim)
@ -2176,12 +2164,12 @@ from psql to update the existing system table:
This will need to be done to every existing database, including template1.
</para>
</sect2>
<sect2>
<para>
<programlisting>
Changes
-------
<sect2>
<title>Changes</title>
<para>
<programlisting>
Allow TIME and TYPE column names(Thomas)
Allow larger range of true/false as boolean values(Thomas)
Support output of "now" and "current"(Thomas)
@ -2193,10 +2181,10 @@ Fix avg(cash) computation(Thomas)
Fix for specifying a column twice in ORDER/GROUP BY(Vadim)
Documented new libpq function to return affected rows, PQcmdTuples(Bruce)
Trigger function for inserting user names for INSERT/UPDATE(Brook Milligan)
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.2</title>
@ -2243,10 +2231,11 @@ because the COPY output format was improved from the 1.02 release.
</para>
</sect2>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Bug Fixes
---------
Fix problems with pg_dump for inheritance, sequences, archive tables(Bruce)
@ -2388,12 +2377,11 @@ Refer to the release notes for v6.1 for more details.
</para>
</sect2>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
Changes
-------
<para>
<programlisting>
fix for SET with options (Thomas)
allow pg_dump/pg_dumpall to preserve ownership of all tables/objects(Bruce)
new psql \connect option allows changing usernames without changing databases
@ -2411,10 +2399,10 @@ major fix for endian handling of communication to server(Thomas, Tatsuo)
Fix for Solaris assembler and include files(Yoshihiko Ichikawa)
allow underscores in usernames(Bruce)
pg_dumpall now returns proper status, portability fix(Bruce)
</programlisting>
</para>
</sect2>
</sect1>
</programlisting>
</para>
</sect2>
</sect1>
<sect1>
<title>Release 6.1</title>
@ -2492,10 +2480,11 @@ because the COPY output format was improved from the 1.02 release.
</para>
</sect2>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Bug Fixes
---------
packet length checking in library routines
@ -2635,10 +2624,11 @@ because the COPY output format was improved from the 1.02 release.
</para>
</sect2>
<sect2>
<sect2>
<title>Changes</title>
<para>
<programlisting>
<para>
<programlisting>
Bug Fixes
---------
ALTER TABLE bug - running postgress process needs to re-read table definition

553
doc/src/sgml/sql.sgml
Unescape 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.9.2.1 2000/06/14 13:18:59 thomas Exp $
-->
<chapter id="sql">
@ -155,20 +155,22 @@ $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
-----+---------+-------- -----+-----
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
1 | Screw | 10
2 | Nut | 8
3 | Bolt | 15
4 | Cam | 25
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: 4 | 3
PNO | PNAME | PRICE 4 | 4
----+---------+---------
1 | Screw | 10
2 | Nut | 8
3 | Bolt | 15
4 | Cam | 25
</programlisting>
</example>
</para>
@ -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,11 +534,12 @@ 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
---+---+--- ---+---+---
1 | 2 | 3 3 | a | b
4 | 5 | 6 6 | c | d
7 | 8 | 9
R: S:
A | B | C C | D | E
---+---+--- ---+---+---
1 | 2 | 3 3 | a | b
4 | 5 | 6 6 | c | d
7 | 8 | 9
</programlisting>
</para>
</example>
@ -547,14 +550,15 @@ attributes are taken from. We often write a relation scheme as
get:
<programlisting>
R x S A | B | R.C | S.C | D | E
---+---+-----+-----+---+---
1 | 2 | 3 | 3 | a | b
1 | 2 | 3 | 6 | c | d
4 | 5 | 6 | 3 | a | b
4 | 5 | 6 | 6 | c | d
7 | 8 | 9 | 3 | a | b
7 | 8 | 9 | 6 | c | d
R x S:
A | B | R.C | S.C | D | E
---+---+-----+-----+---+---
1 | 2 | 3 | 3 | a | b
1 | 2 | 3 | 6 | c | d
4 | 5 | 6 | 3 | a | b
4 | 5 | 6 | 6 | c | d
7 | 8 | 9 | 3 | a | b
7 | 8 | 9 | 6 | c | d
</programlisting>
</para>
@ -564,10 +568,10 @@ attributes are taken from. We often write a relation scheme as
we get:
<programlisting>
A | B | R.C | S.C | D | E
---+---+-----+-----+---+---
1 | 2 | 3 | 3 | a | b
4 | 5 | 6 | 6 | c | d
A | B | R.C | S.C | D | E
---+---+-----+-----+---+---
1 | 2 | 3 | 3 | a | b
4 | 5 | 6 | 6 | c | d
</programlisting>
</para>
@ -579,10 +583,10 @@ attributes are taken from. We often write a relation scheme as
and get:
<programlisting>
A | B | C | D | E
---+---+---+---+---
1 | 2 | 3 | a | b
4 | 5 | 6 | c | d
A | B | C | D | E
---+---+---+---+---
1 | 2 | 3 | a | b
4 | 5 | 6 | c | d
</programlisting>
</para>
</listitem>
@ -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,24 +619,25 @@ 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
---+---+---+--- ---+---
a | b | c | d c | d
a | b | e | f e | f
b | c | e | f
e | d | c | d
e | d | e | f
a | b | d | e
R: S:
A | B | C | D C | D
---+---+---+--- ---+---
a | b | c | d c | d
a | b | e | f e | f
b | c | e | f
e | d | c | d
e | d | e | f
a | b | d | e
</programlisting>
R &divide; S
is derived as
<programlisting>
A | B
---+---
a | b
e | d
A | B
---+---
a | b
e | d
</programlisting>
</para>
</listitem>
@ -668,10 +674,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
we will obtain the following result:
<programlisting>
SNAME
-------
Smith
Adams
SNAME
-------
Smith
Adams
</programlisting>
</para>
</example>
@ -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:
x(A) &mid; F(x)
<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
@ -733,11 +742,11 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
<xref linkend="suppl-rel-alg" endterm="suppl-rel-alg">
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
<programlisting>
{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.
A &lt; B + 3.
<programlisting>
A &lt; B + 3.
</programlisting>
Note
that + or other arithmetic operators appear neither in relational
@ -843,17 +854,17 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
used to retrieve data. The syntax is:
<synopsis>
SELECT [ALL|DISTINCT]
{ * | <replaceable class="parameter">expr_1</replaceable> [AS <replaceable class="parameter">c_alias_1</replaceable>] [, ...
[, <replaceable class="parameter">expr_k</replaceable> [AS <replaceable class="parameter">c_alias_k</replaceable>]]]}
FROM <replaceable class="parameter">table_name_1</replaceable> [<replaceable class="parameter">t_alias_1</replaceable>]
[, ... [, <replaceable class="parameter">table_name_n</replaceable> [<replaceable class="parameter">t_alias_n</replaceable>]]]
[WHERE <replaceable class="parameter">condition</replaceable>]
[GROUP BY <replaceable class="parameter">name_of_attr_i</replaceable>
[,... [, <replaceable class="parameter">name_of_attr_j</replaceable>]] [HAVING <replaceable class="parameter">condition</replaceable>]]
[{UNION [ALL] | INTERSECT | EXCEPT} SELECT ...]
[ORDER BY <replaceable class="parameter">name_of_attr_i</replaceable> [ASC|DESC]
[, ... [, <replaceable class="parameter">name_of_attr_j</replaceable> [ASC|DESC]]]];
SELECT [ALL|DISTINCT]
{ * | <replaceable class="parameter">expr_1</replaceable> [AS <replaceable class="parameter">c_alias_1</replaceable>] [, ...
[, <replaceable class="parameter">expr_k</replaceable> [AS <replaceable class="parameter">c_alias_k</replaceable>]]]}
FROM <replaceable class="parameter">table_name_1</replaceable> [<replaceable class="parameter">t_alias_1</replaceable>]
[, ... [, <replaceable class="parameter">table_name_n</replaceable> [<replaceable class="parameter">t_alias_n</replaceable>]]]
[WHERE <replaceable class="parameter">condition</replaceable>]
[GROUP BY <replaceable class="parameter">name_of_attr_i</replaceable>
[,... [, <replaceable class="parameter">name_of_attr_j</replaceable>]] [HAVING <replaceable class="parameter">condition</replaceable>]]
[{UNION [ALL] | INTERSECT | EXCEPT} SELECT ...]
[ORDER BY <replaceable class="parameter">name_of_attr_i</replaceable> [ASC|DESC]
[, ... [, <replaceable class="parameter">name_of_attr_j</replaceable> [ASC|DESC]]]];
</synopsis>
</para>
@ -876,17 +887,17 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
greater than 10 we formulate the following query:
<programlisting>
SELECT * FROM PART
WHERE PRICE > 10;
SELECT * FROM PART
WHERE PRICE > 10;
</programlisting>
and get the table:
<programlisting>
PNO | PNAME | PRICE
-----+---------+--------
3 | Bolt | 15
4 | Cam | 25
PNO | PNAME | PRICE
-----+---------+--------
3 | Bolt | 15
4 | Cam | 25
</programlisting>
</para>
@ -896,9 +907,9 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
from table PART we use the statement:
<programlisting>
SELECT PNAME, PRICE
FROM PART
WHERE PRICE > 10;
SELECT PNAME, PRICE
FROM PART
WHERE PRICE > 10;
</programlisting>
In this case the result is:
@ -920,18 +931,18 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
using the keywords OR, AND, and NOT:
<programlisting>
SELECT PNAME, PRICE
FROM PART
WHERE PNAME = 'Bolt' AND
SELECT PNAME, PRICE
FROM PART
WHERE PNAME = 'Bolt' AND
(PRICE = 0 OR PRICE < 15);
</programlisting>
will lead to the result:
<programlisting>
PNAME | PRICE
--------+--------
Bolt | 15
PNAME | PRICE
--------+--------
Bolt | 15
</programlisting>
</para>
@ -941,19 +952,19 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
take two pieces of a part we could use the following query:
<programlisting>
SELECT PNAME, PRICE * 2 AS DOUBLE
FROM PART
WHERE PRICE * 2 < 50;
SELECT PNAME, PRICE * 2 AS DOUBLE
FROM PART
WHERE PRICE * 2 < 50;
</programlisting>
and we get:
<programlisting>
PNAME | DOUBLE
--------+---------
Screw | 20
Nut | 16
Bolt | 30
PNAME | DOUBLE
--------+---------
Screw | 20
Nut | 16
Bolt | 30
</programlisting>
Note that the word DOUBLE after the keyword AS is the new title of the
@ -980,25 +991,25 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
attributes we formulate the following statement:
<programlisting>
SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO;
SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO;
</programlisting>
and get the following table as a result:
<programlisting>
SNAME | PNAME
-------+-------
Smith | Screw
Smith | Nut
Jones | Cam
Adams | Screw
Adams | Bolt
Blake | Nut
Blake | Bolt
Blake | Cam
SNAME | PNAME
-------+-------
Smith | Screw
Smith | Nut
Jones | Cam
Adams | Screw
Adams | Bolt
Blake | Nut
Blake | Bolt
Blake | Cam
</programlisting>
</para>
@ -1040,8 +1051,8 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
the following query:
<programlisting>
SELECT AVG(PRICE) AS AVG_PRICE
FROM PART;
SELECT AVG(PRICE) AS AVG_PRICE
FROM PART;
</programlisting>
</para>
@ -1049,9 +1060,9 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
The result is:
<programlisting>
AVG_PRICE
-----------
14.5
AVG_PRICE
-----------
14.5
</programlisting>
</para>
@ -1060,16 +1071,16 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
the statement:
<programlisting>
SELECT COUNT(PNO)
FROM PART;
SELECT COUNT(PNO)
FROM PART;
</programlisting>
and get:
<programlisting>
COUNT
-------
4
COUNT
-------
4
</programlisting>
</para>
@ -1108,21 +1119,21 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
formulate the query:
<programlisting>
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)
FROM SUPPLIER S, SELLS SE
WHERE S.SNO = SE.SNO
GROUP BY S.SNO, S.SNAME;
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)
FROM SUPPLIER S, SELLS SE
WHERE S.SNO = SE.SNO
GROUP BY S.SNO, S.SNAME;
</programlisting>
and get:
<programlisting>
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
2 | Jones | 1
3 | Adams | 2
4 | Blake | 3
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
2 | Jones | 1
3 | Adams | 2
4 | Blake | 3
</programlisting>
</para>
@ -1132,16 +1143,16 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
tables SUPPLIER and SELLS is derived:
<programlisting>
S.SNO | S.SNAME | SE.PNO
-------+---------+--------
1 | Smith | 1
1 | Smith | 2
2 | Jones | 4
3 | Adams | 1
3 | Adams | 3
4 | Blake | 2
4 | Blake | 3
4 | Blake | 4
S.SNO | S.SNAME | SE.PNO
-------+---------+--------
1 | Smith | 1
1 | Smith | 2
2 | Jones | 4
3 | Adams | 1
3 | Adams | 3
4 | Blake | 2
4 | Blake | 3
4 | Blake | 4
</programlisting>
</para>
@ -1150,19 +1161,19 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
together that agree on both attributes S.SNO and S.SNAME:
<programlisting>
S.SNO | S.SNAME | SE.PNO
-------+---------+--------
1 | Smith | 1
| 2
--------------------------
2 | Jones | 4
--------------------------
3 | Adams | 1
| 3
--------------------------
4 | Blake | 2
| 3
| 4
S.SNO | S.SNAME | SE.PNO
-------+---------+--------
1 | Smith | 1
| 2
--------------------------
2 | Jones | 4
--------------------------
3 | Adams | 1
| 3
--------------------------
4 | Blake | 2
| 3
| 4
</programlisting>
</para>
@ -1204,21 +1215,21 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
query:
<programlisting>
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)
FROM SUPPLIER S, SELLS SE
WHERE S.SNO = SE.SNO
GROUP BY S.SNO, S.SNAME
HAVING COUNT(SE.PNO) > 1;
SELECT S.SNO, S.SNAME, COUNT(SE.PNO)
FROM SUPPLIER S, SELLS SE
WHERE S.SNO = SE.SNO
GROUP BY S.SNO, S.SNAME
HAVING COUNT(SE.PNO) > 1;
</programlisting>
and get:
<programlisting>
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
3 | Adams | 2
4 | Blake | 3
SNO | SNAME | COUNT
-----+-------+-------
1 | Smith | 2
3 | Adams | 2
4 | Blake | 3
</programlisting>
</para>
</example>
@ -1243,10 +1254,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
named 'Screw' we use the query:
<programlisting>
SELECT *
FROM PART
WHERE PRICE > (SELECT PRICE FROM PART
WHERE PNAME='Screw');
SELECT *
FROM PART
WHERE PRICE > (SELECT PRICE FROM PART
WHERE PNAME='Screw');
</programlisting>
</para>
@ -1254,10 +1265,10 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
The result is:
<programlisting>
PNO | PNAME | PRICE
-----+---------+--------
3 | Bolt | 15
4 | Cam | 25
PNO | PNAME | PRICE
-----+---------+--------
3 | Bolt | 15
4 | Cam | 25
</programlisting>
</para>
@ -1272,16 +1283,16 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
greater.
</para>
<para>
<para>
If we want to know all suppliers that do not sell any part
(e.g. to be able to remove these suppliers from the database) we use:
<programlisting>
SELECT *
FROM SUPPLIER S
WHERE NOT EXISTS
(SELECT * FROM SELLS SE
WHERE SE.SNO = S.SNO);
SELECT *
FROM SUPPLIER S
WHERE NOT EXISTS
(SELECT * FROM SELLS SE
WHERE SE.SNO = S.SNO);
</programlisting>
</para>
@ -1310,22 +1321,22 @@ t<subscript>r</subscript>(A,B)=t&and;t<subscript>r</subscript>(C,D)=t<subscript>
The following query is an example for UNION:
<programlisting>
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNAME = 'Jones'
UNION
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNAME = 'Adams';
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNAME = 'Jones'
UNION
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNAME = 'Adams';
</programlisting>
gives the result:
<programlisting>
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
3 | Adams | Vienna
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
3 | Adams | Vienna
</programlisting>
</para>
@ -1333,45 +1344,46 @@ gives the result:
Here an example for INTERSECT:
<programlisting>
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 1
INTERSECT
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 2;
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 1
INTERSECT
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 2;
</programlisting>
gives the result:
<programlisting>
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
The only tuple returned by both parts of the query is the one having $SNO=2$.
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
</programlisting>
The only tuple returned by both parts of the query is the one having $SNO=2$.
</para>
<para>
Finally an example for EXCEPT:
<programlisting>
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 1
EXCEPT
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 3;
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 1
EXCEPT
SELECT S.SNO, S.SNAME, S.CITY
FROM SUPPLIER S
WHERE S.SNO > 3;
</programlisting>
gives the result:
<programlisting>
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
3 | Adams | Vienna
SNO | SNAME | CITY
-----+-------+--------
2 | Jones | Paris
3 | Adams | Vienna
</programlisting>
</para>
</example>
@ -1395,11 +1407,11 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
one that creates a new relation (a new table). The syntax of the
CREATE TABLE command is:
<synopsis>
CREATE TABLE <replaceable class="parameter">table_name</replaceable>
(<replaceable class="parameter">name_of_attr_1</replaceable> <replaceable class="parameter">type_of_attr_1</replaceable>
[, <replaceable class="parameter">name_of_attr_2</replaceable> <replaceable class="parameter">type_of_attr_2</replaceable>
[, ...]]);
<synopsis>
CREATE TABLE <replaceable class="parameter">table_name</replaceable>
(<replaceable class="parameter">name_of_attr_1</replaceable> <replaceable class="parameter">type_of_attr_1</replaceable>
[, <replaceable class="parameter">name_of_attr_2</replaceable> <replaceable class="parameter">type_of_attr_2</replaceable>
[, ...]]);
</synopsis>
<example>
@ -1411,23 +1423,23 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
following <acronym>SQL</acronym> statements are used:
<programlisting>
CREATE TABLE SUPPLIER
(SNO INTEGER,
SNAME VARCHAR(20),
CITY VARCHAR(20));
</programlisting>
CREATE TABLE SUPPLIER
(SNO INTEGER,
SNAME VARCHAR(20),
CITY VARCHAR(20));
</programlisting>
<programlisting>
CREATE TABLE PART
(PNO INTEGER,
PNAME VARCHAR(20),
PRICE DECIMAL(4 , 2));
</programlisting>
<programlisting>
CREATE TABLE PART
(PNO INTEGER,
PNAME VARCHAR(20),
PRICE DECIMAL(4 , 2));
</programlisting>
<programlisting>
CREATE TABLE SELLS
(SNO INTEGER,
PNO INTEGER);
<programlisting>
CREATE TABLE SELLS
(SNO INTEGER,
PNO INTEGER);
</programlisting>
</para>
</example>
@ -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.
@ -1514,8 +1526,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
the CREATE INDEX command is used. The syntax is:
<programlisting>
CREATE INDEX <replaceable class="parameter">index_name</replaceable>
ON <replaceable class="parameter">table_name</replaceable> ( <replaceable class="parameter">name_of_attribute</replaceable> );
CREATE INDEX <replaceable class="parameter">index_name</replaceable>
ON <replaceable class="parameter">table_name</replaceable> ( <replaceable class="parameter">name_of_attribute</replaceable> );
</programlisting>
</para>
@ -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>
@ -1578,8 +1589,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
is:
<programlisting>
CREATE VIEW <replaceable class="parameter">view_name</replaceable>
AS <replaceable class="parameter">select_stmt</replaceable>
CREATE VIEW <replaceable class="parameter">view_name</replaceable>
AS <replaceable class="parameter">select_stmt</replaceable>
</programlisting>
where <replaceable class="parameter">select_stmt</replaceable>
@ -1597,12 +1608,12 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
<xref linkend="supplier-fig" endterm="supplier-fig"> again):
<programlisting>
CREATE VIEW London_Suppliers
AS SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO AND
S.CITY = 'London';
CREATE VIEW London_Suppliers
AS SELECT S.SNAME, P.PNAME
FROM SUPPLIER S, PART P, SELLS SE
WHERE S.SNO = SE.SNO AND
P.PNO = SE.PNO AND
S.CITY = 'London';
</programlisting>
</para>
@ -1612,17 +1623,16 @@ 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
WHERE P.PNAME = 'Screw';
SELECT * FROM London_Suppliers
WHERE P.PNAME = 'Screw';
</programlisting>
which will return the following table:
<programlisting>
SNAME | PNAME
-------+-------
Smith | Screw
SNAME | PNAME
-------+-------
Smith | Screw
</programlisting>
</para>
@ -1646,7 +1656,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
DROP TABLE command is used:
<programlisting>
DROP TABLE <replaceable class="parameter">table_name</replaceable>;
DROP TABLE <replaceable class="parameter">table_name</replaceable>;
</programlisting>
</para>
@ -1654,7 +1664,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
To destroy the SUPPLIER table use the following statement:
<programlisting>
DROP TABLE SUPPLIER;
DROP TABLE SUPPLIER;
</programlisting>
</para>
@ -1662,7 +1672,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
The DROP INDEX command is used to destroy an index:
<programlisting>
DROP INDEX <replaceable class="parameter">index_name</replaceable>;
DROP INDEX <replaceable class="parameter">index_name</replaceable>;
</programlisting>
</para>
@ -1670,7 +1680,7 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
Finally to destroy a given view use the command DROP VIEW:
<programlisting>
DROP VIEW <replaceable class="parameter">view_name</replaceable>;
DROP VIEW <replaceable class="parameter">view_name</replaceable>;
</programlisting>
</para>
</sect3>
@ -1689,10 +1699,9 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
The syntax is:
<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> [, ...]]);
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> [, ...]]);
</programlisting>
</para>
@ -1702,8 +1711,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
following statement:
<programlisting>
INSERT INTO SUPPLIER (SNO, SNAME, CITY)
VALUES (1, 'Smith', 'London');
INSERT INTO SUPPLIER (SNO, SNAME, CITY)
VALUES (1, 'Smith', 'London');
</programlisting>
</para>
@ -1711,8 +1720,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
To insert the first tuple into the relation SELLS we use:
<programlisting>
INSERT INTO SELLS (SNO, PNO)
VALUES (1, 1);
INSERT INTO SELLS (SNO, PNO)
VALUES (1, 1);
</programlisting>
</para>
</sect3>
@ -1725,10 +1734,10 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
UPDATE command is used. The syntax is:
<programlisting>
UPDATE <replaceable class="parameter">table_name</replaceable>
SET <replaceable class="parameter">name_of_attr_1</replaceable> = <replaceable class="parameter">value_1</replaceable>
[, ... [, <replaceable class="parameter">name_of_attr_k</replaceable> = <replaceable class="parameter">value_k</replaceable>]]
WHERE <replaceable class="parameter">condition</replaceable>;
UPDATE <replaceable class="parameter">table_name</replaceable>
SET <replaceable class="parameter">name_of_attr_1</replaceable> = <replaceable class="parameter">value_1</replaceable>
[, ... [, <replaceable class="parameter">name_of_attr_k</replaceable> = <replaceable class="parameter">value_k</replaceable>]]
WHERE <replaceable class="parameter">condition</replaceable>;
</programlisting>
</para>
@ -1737,9 +1746,9 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
relation PART we use:
<programlisting>
UPDATE PART
SET PRICE = 15
WHERE PNAME = 'Screw';
UPDATE PART
SET PRICE = 15
WHERE PNAME = 'Screw';
</programlisting>
</para>
@ -1757,8 +1766,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
FROM. The syntax is:
<programlisting>
DELETE FROM <replaceable class="parameter">table_name</replaceable>
WHERE <replaceable class="parameter">condition</replaceable>;
DELETE FROM <replaceable class="parameter">table_name</replaceable>
WHERE <replaceable class="parameter">condition</replaceable>;
</programlisting>
</para>
@ -1767,8 +1776,8 @@ The only tuple returned by both parts of the query is the one having $SNO=2$.
following statement is used:
<programlisting>
DELETE FROM SUPPLIER
WHERE SNAME = 'Smith';
DELETE FROM SUPPLIER
WHERE SNAME = 'Smith';
</programlisting>
</para>
</sect3>

Write Preview
Loading…
Cancel
Save