Avoid referring to a specific version of the SQL standard except where

necessary, and be careful to refer to the right version where it is
useful to do so.  This partially reverts an ill-considered search and
replace from a few months ago.

doc/src/sgml/array.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.44 2005/07/14 06:17:35 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/array.sgml,v 1.45 2005/11/04 02:56:30 tgl Exp $ -->
 
 <sect1 id="arrays">
  <title>Arrays</title>
@@ -63,7 +63,7 @@ CREATE TABLE tictactoe (
  </para>
 
  <para>
-  An alternative syntax, which conforms to the SQL:2003 standard, may
+  An alternative syntax, which conforms to the SQL standard, may
   be used for one-dimensional arrays.
   <structfield>pay_by_quarter</structfield> could have been defined
   as:

doc/src/sgml/ddl.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.47 2005/11/03 00:51:43 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/ddl.sgml,v 1.48 2005/11/04 02:56:30 tgl Exp $ -->
 
 <chapter id="ddl">
  <title>Data Definition</title>
@@ -1058,8 +1058,8 @@ CREATE TABLE order_items (
 
   <para>
    <productname>PostgreSQL</productname> implements table inheritance
-   which can be a useful tool for database designers.  The SQL:2003
-   standard optionally defines type inheritance which differs in many
+   which can be a useful tool for database designers.  SQL:1999 and
+   later define a type inheritance feature, which differs in many
    respects from the features described here.
   </para>
 
@@ -1323,7 +1323,7 @@ WHERE c.altitude &gt; 500 and c.tableoid = p.oid;
    <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:2003
+     found to be error prone and is also in violation of the SQL
      standard. Under the old syntax, to get the sub-tables you append
      <literal>*</literal> to the table name. For example:
 <programlisting>
@@ -1364,7 +1364,7 @@ SELECT * from cities*;
 
    <para>
     Currently, partitioning is implemented in conjunction with table
-    inheritance only, though using fully SQL:2003 compliant syntax.
+    inheritance only, though using fully SQL compliant syntax.
     Table inheritance allows tables to be split into partitions, and
     constraint exclusion allows partitions to be selectively combined
     as needed to satisfy a particular <command>SELECT</command>

doc/src/sgml/ecpg.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.69 2005/10/13 17:55:18 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ecpg.sgml,v 1.70 2005/11/04 02:56:30 tgl Exp $
 -->
 
 <chapter id="ecpg">
@@ -1145,8 +1145,8 @@ struct
    <para>
     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 SQL-92
+    provide error codes.  Both are derived from the SQL standard, but
+    <literal>SQLCODE</literal> has been marked deprecated in the SQL-92
     edition of the standard and has been dropped in later editions.
     Therefore, new applications are strongly encouraged to use
     <literal>SQLSTATE</literal>.

doc/src/sgml/errcodes.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.14 2005/07/14 06:17:35 neilc Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/errcodes.sgml,v 1.15 2005/11/04 02:56:30 tgl Exp $ -->
 
 <appendix id="errcodes-appendix">
  <title><productname>PostgreSQL</productname> Error Codes</title>
@@ -127,7 +127,7 @@
 
 <row>
 <entry>Class 02</entry>
-<entry>No Data &mdash; this is also a warning class per SQL:2003</entry>
+<entry>No Data &mdash; this is also a warning class per the SQL standard</entry>
 </row>
 
 <row>

doc/src/sgml/func.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.289 2005/10/25 15:47:51 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/func.sgml,v 1.290 2005/11/04 02:56:30 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -2675,8 +2675,9 @@ 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 (part of 
-    SQL:2003), and <acronym>POSIX</acronym>-style regular expressions.
+    more recent <function>SIMILAR TO</function> operator (added in
+    SQL:1999), 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

doc/src/sgml/intro.sgml

 <!--
-$PostgreSQL: pgsql/doc/src/sgml/intro.sgml,v 1.29 2005/04/09 03:52:43 momjian Exp $
+$PostgreSQL: pgsql/doc/src/sgml/intro.sgml,v 1.30 2005/11/04 02:56:31 tgl Exp $
 -->
 
 <preface id="preface">
@@ -98,7 +98,7 @@ $PostgreSQL: pgsql/doc/src/sgml/intro.sgml,v 1.29 2005/04/09 03:52:43 momjian Ex
 
   <para>
    <productname>PostgreSQL</productname> is an open-source descendant
-   of this original Berkeley code.  It supports a large part of the SQL:2003
+   of this original Berkeley code.  It supports a large part of the SQL
    standard and offers many modern features:
 
    <itemizedlist spacing="compact">