This doc patch replaces all inappropriate references to SQL:1999 when it
authorNeil Conway <neilc@samurai.com>
Thu, 14 Jul 2005 06:17:36 +0000 (06:17 +0000)
committerNeil Conway <neilc@samurai.com>
Thu, 14 Jul 2005 06:17:36 +0000 (06:17 +0000)
is used as if it were the latest (and/or still valid) SQL standard.
SQL:2003 is used in its place. Patch from Simon Riggs.

13 files changed:
doc/src/sgml/array.sgml
doc/src/sgml/ddl.sgml
doc/src/sgml/ecpg.sgml
doc/src/sgml/errcodes.sgml
doc/src/sgml/func.sgml
doc/src/sgml/ref/alter_domain.sgml
doc/src/sgml/ref/create_cast.sgml
doc/src/sgml/ref/create_function.sgml
doc/src/sgml/ref/create_table.sgml
doc/src/sgml/ref/create_trigger.sgml
doc/src/sgml/ref/create_type.sgml
doc/src/sgml/ref/select.sgml
doc/src/sgml/sql.sgml

index 36bf2a7e5c29a2d8dad2335201069a653b39488f..8c8fe1bf0d514cffba14932487702c2e20b47073 100644 (file)
@@ -63,7 +63,7 @@ CREATE TABLE tictactoe (
  </para>
 
  <para>
-  An alternative syntax, which conforms to the SQL:1999 standard, may
+  An alternative syntax, which conforms to the SQL:2003 standard, may
   be used for one-dimensional arrays.
   <structfield>pay_by_quarter</structfield> could have been defined
   as:
index 5771aad840fbfb3f9d6275f39d96c3946147764d..d676ce2a169094ce050ca2885ebc9743bb0312c9 100644 (file)
@@ -1122,7 +1122,7 @@ SELECT name, altitude
    <para>
      In previous versions of <productname>PostgreSQL</productname>, the
      default behavior was not to include child tables in queries. This was
-     found to be error prone and is also in violation of the SQL:1999
+     found to be error prone and is also in violation of the SQL:2003
      standard. Under the old syntax, to get the sub-tables you append
      <literal>*</literal> to the table name.
      For example
index 4c393ce7de0c4c7ba24ebe232ef2813ca32aecb9..b73c377bafed2abe52066da8981141466bc41d72 100644 (file)
@@ -1146,8 +1146,8 @@ struct
     The fields <literal>sqlca.sqlstate</literal> and
     <literal>sqlca.sqlcode</literal> are two different schemes that
     provide error codes.  Both are specified in the SQL standard, but
-    <literal>SQLCODE</literal> has been marked deprecated in the 1992
-    edition of the standard and has been dropped in the 1999 edition.
+    <literal>SQLCODE</literal> has been marked deprecated in SQL-92
+    edition of the standard and has been dropped in later editions.
     Therefore, new applications are strongly encouraged to use
     <literal>SQLSTATE</literal>.
    </para>
index 1e42cb882cde175d7f0bd401e8bcd610967af9d6..bcfc6e3726b2b0ed79c8b4aba573f58036c2a00b 100644 (file)
 
 <row>
 <entry>Class 02</entry>
-<entry>No Data &mdash; this is also a warning class per SQL:1999</entry>
+<entry>No Data &mdash; this is also a warning class per SQL:2003</entry>
 </row>
 
 <row>
index e8365a273a6302e5a0afb91eab11caeba46d7836..3d1359eba5a91439b265f751adecca4fe60f19d7 100644 (file)
@@ -2543,8 +2543,8 @@ cast(-44 as bit(12))           <lineannotation>111111010100</lineannotation>
     There are three separate approaches to pattern matching provided
     by <productname>PostgreSQL</productname>: the traditional
     <acronym>SQL</acronym> <function>LIKE</function> operator, the
-    more recent <function>SIMILAR TO</function> operator (added in
-    SQL:1999), and <acronym>POSIX</acronym>-style regular expressions.
+    more recent <function>SIMILAR TO</function> operator (part of 
+    SQL:2003), and <acronym>POSIX</acronym>-style regular expressions.
     Additionally, a pattern matching function,
     <function>substring</function>, is available, using either
     <function>SIMILAR TO</function>-style or POSIX-style regular
index f7987b3557c09d8b580e7663db7734bb1f16f9cc..6e9b64ed5c389f160609c74699c53ac1c5394281 100644 (file)
@@ -203,7 +203,7 @@ ALTER DOMAIN zipcode DROP CONSTRAINT zipchk;
   <title>Compatibility</title>
     
   <para>
-   The <command>ALTER DOMAIN</command> statement is compatible with SQL:1999,
+   The <command>ALTER DOMAIN</command> statement is compatible with SQL:2003,
    except for the <literal>OWNER</> variant, which is a
    <productname>PostgreSQL</productname> extension.
   </para>
index 20ce16620a2329825e67d7c8d05312bc802045aa..d3f89fddd74271ca385398ed7a28e9d44dc27b5e 100644 (file)
@@ -298,8 +298,8 @@ CREATE CAST (text AS int4) WITH FUNCTION int4(text);
   <title>Compatibility</title>
 
   <para>
-   The <command>CREATE CAST</command> command conforms to SQL:1999,
-   except that SQL:1999 does not make provisions for binary-compatible
+   The <command>CREATE CAST</command> command conforms to SQL:2003,
+   except that SQL:2003 does not make provisions for binary-compatible
    types or extra arguments to implementation functions.
    <literal>AS IMPLICIT</> is a <productname>PostgreSQL</productname> 
    extension, too.
index 39021f4d6d98140352f6fff272195e8cd6d8917f..0a2cab49adacd51c4c45a4fef4d3106da15e2761 100644 (file)
@@ -478,7 +478,7 @@ SELECT * FROM dup(42);
   <title>Compatibility</title>
 
   <para>
-   A <command>CREATE FUNCTION</command> command is defined in SQL:1999 and later.
+   A <command>CREATE FUNCTION</command> command is defined in SQL:2003.
    The <productname>PostgreSQL</productname> version is similar but
    not fully compatible.  The attributes are not portable, neither are the
    different available languages.
index 05fc7a1981aa7fd202395ba45197ba215d02c777..84d1f7c5ef0ac99fde078a6c3b1932b51923bdd4 100644 (file)
@@ -860,7 +860,7 @@ CREATE TABLE cinemas (
 
   <para>
    The <command>CREATE TABLE</command> command conforms to SQL-92 and
-   to a subset of SQL:1999, with exceptions listed below.
+   to a subset of SQL:2003, with exceptions listed below.
   </para>
 
   <refsect2>
@@ -938,8 +938,8 @@ CREATE TABLE cinemas (
    <para>
     Multiple inheritance via the <literal>INHERITS</literal> clause is
     a <productname>PostgreSQL</productname> language extension.
-    SQL:1999 (but not SQL-92) defines single inheritance using a
-    different syntax and different semantics.  SQL:1999-style
+    SQL:2003 defines single inheritance using a
+    different syntax and different semantics.  SQL:2003-style
     inheritance is not yet supported by
     <productname>PostgreSQL</productname>.
    </para>
index 63f960baafe3fbdbe12ad5e5a1664ea8e891455e..4d5ef999118bf610bb6a6df2425e19d06f071cb4 100644 (file)
@@ -208,20 +208,19 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
   <para>
    The <command>CREATE TRIGGER</command> statement in
    <productname>PostgreSQL</productname> implements a subset of the
-   SQL:1999 standard.  (There are no provisions for triggers in SQL-92.)
-   The following functionality is missing:
+   SQL:2003 standard. The following functionality is currently missing:
 
    <itemizedlist>
     <listitem>
      <para>
-      SQL:1999 allows triggers to fire on updates to specific columns
+      SQL:2003 allows triggers to fire on updates to specific columns
       (e.g., <literal>AFTER UPDATE OF col1, col2</literal>).
      </para>
     </listitem>
 
     <listitem>
      <para>
-      SQL:1999 allows you to define aliases for the <quote>old</quote>
+      SQL:2003 allows you to define aliases for the <quote>old</quote>
       and <quote>new</quote> rows or tables for use in the definition
       of the triggered action (e.g., <literal>CREATE TRIGGER ... ON
       tablename REFERENCING OLD ROW AS somename NEW ROW AS othername
@@ -235,7 +234,7 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
     <listitem>
      <para>
       <productname>PostgreSQL</productname> only allows the execution
-      of a user-defined function for the triggered action.  SQL:1999
+      of a user-defined function for the triggered action.  SQL:2003
       allows the execution of a number of other SQL commands, such as
       <command>CREATE TABLE</command> as triggered action.  This
       limitation is not hard to work around by creating a user-defined
@@ -246,7 +245,7 @@ CREATE TRIGGER <replaceable class="PARAMETER">name</replaceable> { BEFORE | AFTE
   </para>
 
   <para>
-   SQL:1999 specifies that multiple triggers should be fired in
+   SQL:2003 specifies that multiple triggers should be fired in
    time-of-creation order.  <productname>PostgreSQL</productname> uses
    name order, which was judged more convenient to work with.
   </para>
index 9a22ede7cb8606ea86e02177f654cfa2662e651c..0229d325e11a2cc67341a23afedd3c97c4a4e630 100644 (file)
@@ -533,7 +533,7 @@ CREATE TABLE big_objs (
   <para>
    This <command>CREATE TYPE</command> command is a
    <productname>PostgreSQL</productname> extension.  There is a
-   <command>CREATE TYPE</command> statement in SQL:1999 and later that is rather
+   <command>CREATE TYPE</command> statement in SQL:2003 that is rather
    different in detail.
   </para>
  </refsect1>
index 0158798a40d4e32bd3f4e393baed1c1b18f05d02..cba03cb2b14638489efc2509226155dc6f74ed05 100644 (file)
@@ -1082,7 +1082,7 @@ SELECT distributors.* WHERE distributors.name = 'Westward';
    <title>Namespace Available to <literal>GROUP BY</literal> and <literal>ORDER BY</literal></title>
 
    <para>
-    In the SQL-92 standard, an <literal>ORDER BY</literal> clause may
+    In the SQL:2003 standard, an <literal>ORDER BY</literal> clause may
     only use result column names or numbers, while a <literal>GROUP
     BY</literal> clause may only use expressions based on input column
     names.  <productname>PostgreSQL</productname> extends each of
@@ -1095,11 +1095,11 @@ SELECT distributors.* WHERE distributors.name = 'Westward';
    </para>
 
    <para>
-    SQL:1999 uses a slightly different definition which is not entirely upward
-    compatible 
-    with SQL-92.  In most cases, however, <productname>PostgreSQL</productname>
+    SQL:2003 uses a slightly different definition which is not entirely upward
+    compatible with SQL-92.  
+    In most cases, however, <productname>PostgreSQL</productname>
     will interpret an <literal>ORDER BY</literal> or <literal>GROUP
-    BY</literal> expression the same way SQL:1999 does.
+    BY</literal> expression the same way SQL:2003 does.
    </para>
   </refsect2>
 
index f0b3140d5ccf180fa39e2a0c718162f4849b9e30..5b52476f4191fe93aae1ec8aeb8f7c7a66501134 100644 (file)
@@ -98,8 +98,7 @@ $PostgreSQL$
    is under development. It is planned to make <acronym>SQL</acronym>
    a Turing-complete
    language, i.e. all computable queries (e.g. recursive queries) will be
-   possible. This is a very complex task and therefore the completion of
-   the new standard can not be expected before 1999.
+   possible. This has now been completed as SQL:2003.
   </para>
 
   <sect1 id="rel-model">