Updates for schema features.

doc/src/sgml/datatype.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.90 2002/04/25 02:56:55 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/datatype.sgml,v 1.91 2002/04/25 20:14:43 tgl Exp $
 -->
 
  <chapter id="datatype">
@@ -2924,6 +2924,18 @@ SELECT SUBSTRING(b FROM 1 FOR 2) FROM test;
     <primary>regtype</primary>
    </indexterm>
 
+   <indexterm zone="datatype-oid">
+    <primary>xid</primary>
+   </indexterm>
+
+   <indexterm zone="datatype-oid">
+    <primary>cid</primary>
+   </indexterm>
+
+   <indexterm zone="datatype-oid">
+    <primary>tid</primary>
+   </indexterm>
+
    <para>
     Object identifiers (OIDs) are used internally by
     <productname>PostgreSQL</productname> as primary keys for various system
@@ -3034,7 +3046,7 @@ SELECT SUBSTRING(b FROM 1 FOR 2) FROM test;
    </para>
 
    <para>
-    All of the alias types accept schema-qualified names, and will
+    All of the OID alias types accept schema-qualified names, and will
     display schema-qualified names on output if the object would not
     be found in the current search path without being qualified.
     The <type>regproc</> and <type>regoper</> alias types will only
@@ -3045,6 +3057,52 @@ SELECT SUBSTRING(b FROM 1 FOR 2) FROM test;
     operand.
    </para>
 
+   <para>
+    OIDs are 32-bit quantities and are assigned from a single cluster-wide
+    counter.  In a large or long-lived database, it is possible for the
+    counter to wrap around.  Hence, it is bad practice to assume that OIDs
+    are unique, unless you take steps to ensure that they are unique.
+    Recommended practice when using OIDs for row identification is to create
+    a unique constraint on the OID column of each table for which the OID will
+    be used.  Never assume that OIDs are unique across tables; use the
+    combination of <structfield>tableoid</> and row OID if you need a
+    database-wide identifier.  (Future releases of
+    <productname>PostgreSQL</productname> are likely to use a separate
+    OID counter for each table, so that <structfield>tableoid</>
+    <emphasis>must</> be included to arrive at a globally unique identifier.)
+   </para>
+
+   <para>
+    Another identifier type used by the system is <type>xid</>, or transaction
+    (abbreviated xact) identifier.  This is the datatype of the system columns
+    <structfield>xmin</> and <structfield>xmax</>.
+    Transaction identifiers are 32-bit quantities.  In a long-lived
+    database it is possible for transaction IDs to wrap around.  This
+    is not a fatal problem given appropriate maintenance procedures;
+    see the <citetitle>Administrator's Guide</> for details.  However, it is
+    unwise to depend on uniqueness of transaction IDs over the long term
+    (more than one billion transactions).
+   </para>
+
+   <para>
+    A third identifier type used by the system is <type>cid</>, or command
+    identifier.  This is the datatype of the system columns
+    <structfield>cmin</> and <structfield>cmax</>.
+    Command identifiers are also 32-bit quantities.  This creates a hard
+    limit of 2<superscript>32</> (4 billion) SQL commands within a single
+    transaction.
+    In practice this limit is not a problem --- note that the limit is on
+    number of SQL queries, not number of tuples processed.
+   </para>
+
+   <para>
+    A final identifier type used by the system is <type>tid</>, or tuple
+    identifier.  This is the datatype of the system column
+    <structfield>ctid</>.  A tuple ID is a pair
+    (block number, tuple index within block) that identifies the
+    physical location of the tuple within its table.
+   </para>
+
   </sect1>
 
  </chapter>

doc/src/sgml/queries.sgml

-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.14 2001/11/28 20:49:10 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/queries.sgml,v 1.15 2002/04/25 20:14:43 tgl Exp $ -->
 
 <chapter id="queries">
  <title>Queries</title>
@@ -86,7 +86,8 @@ SELECT random();
 FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_reference</replaceable> <optional>, ...</optional></optional>
 </synopsis>
 
-    A table reference may be a table name or a derived table such as a
+    A table reference may be a table name (possibly schema-qualified),
+    or a derived table such as a
     subquery, a table join, or complex combinations of these.  If more
     than one table reference is listed in the FROM clause they are
     cross-joined (see below) to form the derived table that may then

doc/src/sgml/typeconv.sgml

@@ -228,7 +228,32 @@ should use this new function and will no longer do the implicit conversion using
 
 <step performance="required">
 <para>
-Check for an exact match in the <classname>pg_operator</classname> system catalog.
+Select the operators to be considered from the
+<classname>pg_operator</classname> system catalog.  If an unqualified
+operator name is used (the usual case), the operators
+considered are those of the right name and argument count that are
+visible in the current search path (see <xref linkend="sql-naming">).
+If a qualified operator name was given, only operators in the specified
+schema are considered.
+</para>
+
+<substeps>
+<step performance="optional">
+<para>
+If the search path finds multiple operators of identical argument types,
+only the one appearing earliest in the path is considered.  But operators of
+different argument types are considered on an equal footing regardless of
+search path position.
+</para>
+</step>
+</substeps>
+</step>
+
+<step performance="required">
+<para>
+Check for an operator accepting exactly the input argument types.
+If one exists (there can be only one exact match in the set of
+operators considered), use it.
 </para>
 
 <substeps>
@@ -250,10 +275,11 @@ Look for the best match.
 <substeps>
 <step performance="required">
 <para>
-Make a list of all operators of the same name for which the input types
-match or can be coerced to match.  (<type>unknown</type> literals are
-assumed to be coercible to anything for this purpose.)  If there is only
-one, use it; else continue to the next step.
+Discard candidate operators for which the input types do not match
+and cannot be coerced (using an implicit coercion function) to match.
+<type>unknown</type> literals are
+assumed to be coercible to anything for this purpose.  If only one
+candidate remains, use it; else continue to the next step.
 </para>
 </step>
 <step performance="required">
@@ -467,13 +493,38 @@ tgl=> select cast(text '20' as int8) ! as "factorial";
 
 <step performance="required">
 <para>
-Check for an exact match in the <classname>pg_proc</classname> system catalog.
+Select the functions to be considered from the
+<classname>pg_proc</classname> system catalog.  If an unqualified
+function name is used, the functions
+considered are those of the right name and argument count that are
+visible in the current search path (see <xref linkend="sql-naming">).
+If a qualified function name was given, only functions in the specified
+schema are considered.
+</para>
+
+<substeps>
+<step performance="optional">
+<para>
+If the search path finds multiple functions of identical argument types,
+only the one appearing earliest in the path is considered.  But functions of
+different argument types are considered on an equal footing regardless of
+search path position.
+</para>
+</step>
+</substeps>
+</step>
+
+<step performance="required">
+<para>
+Check for a function accepting exactly the input argument types.
+If one exists (there can be only one exact match in the set of
+functions considered), use it.
 (Cases involving <type>unknown</type> will never find a match at
 this step.)
 </para></step>
 <step performance="required">
 <para>
-If no exact match appears in the catalog, see whether the function call appears
+If no exact match is found, see whether the function call appears
 to be a trivial type coercion request.  This happens if the function call
 has just one argument and the function name is the same as the (internal)
 name of some data type.  Furthermore, the function argument must be either
@@ -489,11 +540,11 @@ Look for the best match.
 <substeps>
 <step performance="required">
 <para>
-Make a list of all functions of the same name with the same number of
-arguments for which the input types
-match or can be coerced to match.  (<type>unknown</type> literals are
-assumed to be coercible to anything for this purpose.)  If there is only
-one, use it; else continue to the next step.
+Discard candidate functions for which the input types do not match
+and cannot be coerced (using an implicit coercion function) to match.
+<type>unknown</type> literals are
+assumed to be coercible to anything for this purpose.  If only one
+candidate remains, use it; else continue to the next step.
 </para>
 </step>
 <step performance="required">