diff --git a/doc/src/sgml/keys.sgml b/doc/src/sgml/keys.sgml
deleted file mode 100644
index c1a454a2b4e5b513c6b772596a0276e90b343f88..0000000000000000000000000000000000000000
--- a/doc/src/sgml/keys.sgml
+++ /dev/null
@@ -1,186 +0,0 @@
-<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/keys.sgml,v 1.7 2000/12/22 21:51:58 petere Exp $
-Indices and Keys
--->
-
- <chapter id="keys">
- <docinfo>
- <authorgroup>
- <author>
- <firstname>Herouth</firstname>
- <surname>Maoz</surname>
- </author>
- </authorgroup>
- <date>1998-03-02</date>
- </docinfo>
-
- <title>Indices and Keys</title>
-
- <note>
- <title>Author</title>
- <para>
- Written by Herouth Maoz
- (<email>herouth@oumail.openu.ac.il</email>)
- </para>
- </note>
-
- <note>
- <title>Editor's Note</title>
- <para>
- This originally appeared on the mailing list
- in response to the question:
- "What is the difference between PRIMARY KEY and UNIQUE constraints?".
- </para>
- </note>
-
- <programlisting>
-Subject: Re: [QUESTIONS] PRIMARY KEY | UNIQUE
-
- What's the difference between:
-
- PRIMARY KEY(fields,...) and
- UNIQUE (fields,...)
-
- - Is this an alias?
- - If PRIMARY KEY is already unique, then why
- is there another kind of key named UNIQUE?
- </programlisting>
-
- <para>
- A primary key is the field(s) used to identify a specific row. For example,
- Social Security numbers identifying a person.
- </para>
- <para>
- A simply UNIQUE combination of fields has nothing to do with identifying
- the row. It's simply an integrity constraint. For example, I have
- collections of links. Each collection is identified by a unique number,
- which is the primary key. This key is used in relations.
- </para>
- <para>
- However, my application requires that each collection will also have a
- unique name. Why? So that a human being who wants to modify a collection
- will be able to identify it. It's much harder to know, if you have two
- collections named "Life Science", the the one tagged 24433 is the one you
- need, and the one tagged 29882 is not.
- </para>
- <para>
- So, the user selects the collection by its name. We therefore make sure,
- withing the database, that names are unique. However, no other table in the
- database relates to the collections table by the collection Name. That
- would be very inefficient.
- </para>
- <para>
- Moreover, despite being unique, the collection name does not actually
- define the collection! For example, if somebody decided to change the name
- of the collection from "Life Science" to "Biology", it will still be the
- same collection, only with a different name. As long as the name is unique,
- that's OK.
- </para>
- <para>
- So:
-
- <itemizedlist>
- <listitem>
- <para>
- Primary key:
- <itemizedlist>
- <listitem>
- <para>
- Is used for identifying the row and relating to it.
- </para>
- </listitem>
- <listitem>
- <para>
- Is impossible (or hard) to update.
- </para>
- </listitem>
- <listitem>
- <para>
- Should not allow NULLs.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
-
- <listitem>
- <para>
- Unique field(s):
- <itemizedlist>
- <listitem>
- <para>
- Are used as an alternative access to the row.
- </para>
- </listitem>
- <listitem>
- <para>
- Are updateable, so long as they are kept unique.
- </para>
- </listitem>
- <listitem>
- <para>
- NULLs are acceptable.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- As for why no non-unique keys are defined explicitly in standard
- <acronym>SQL</acronym> syntax?
- Well, you
- must understand that indices are implementation-dependent. <acronym>SQL</acronym> does not
- define the implementation, merely the relations between data in the
- database. <productname>Postgres</productname> does allow non-unique indices, but indices
- used to enforce <acronym>SQL</acronym> keys are always unique.
- </para>
- <para>
- Thus, you may query a table by any combination of its columns, despite the
- fact that you don't have an index on these columns. The indexes are merely
- an implementational aid that each <acronym>RDBMS</acronym> offers you, in order to cause
- commonly used queries to be done more efficiently. Some <acronym>RDBMS</acronym> may give you
- additional measures, such as keeping a key stored in main memory. They will
- have a special command, for example
- <programlisting>
- CREATE MEMSTORE ON <table> COLUMNS <cols>
- </programlisting>
- (this is not an existing command, just an example).
- </para>
- <para>
- In fact, when you create a primary key or a unique combination of fields,
- nowhere in the <acronym>SQL</acronym> specification does it say that an index is created, nor that
- the retrieval of data by the key is going to be more efficient than a
- sequential scan!
- </para>
- <para>
- So, if you want to use a combination of fields that is not unique as a
- secondary key, you really don't have to specify anything - just start
- retrieving by that combination! However, if you want to make the retrieval
- efficient, you'll have to resort to the means your <acronym>RDBMS</acronym> provider gives you
- - be it an index, my imaginary MEMSTORE command, or an intelligent
- <acronym>RDBMS</acronym>
- that creates indices without your knowledge based on the fact that you have
- sent it many queries based on a specific combination of keys... (It learns
- from experience).
- </para>
- </chapter>
-
-<!-- Keep this comment at the end of the file
-Local variables:
-mode:sgml
-sgml-omittag:nil
-sgml-shorttag:t
-sgml-minimize-attributes:nil
-sgml-always-quote-attributes:t
-sgml-indent-step:1
-sgml-indent-data:t
-sgml-parent-document:nil
-sgml-default-dtd-file:"./reference.ced"
-sgml-exposed-tags:nil
-sgml-local-catalogs:("/usr/lib/sgml/catalog")
-sgml-local-ecat-files:nil
-End:
---></book>