doc: Remove more notes about compatibilities with past versions

This is a follow-up of the work done in fa42c2e, that did not include
all the fixes previously agreed on.  The contents removed here can be
confusing to the reader as they refer to rather old server versions.

Author: Stephen Frost, Tom Lane, Heikki Linnakangas, Yaroslav Schekin
Discussion: https://postgr.es/m/CAB8KJ=jYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA@mail.gmail.com
Discussion: https://postgr.es/m/1599765595731-0.post@n3.nabble.com

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 507bc1a66837f7369b3e39d6b1a974b5356cc84d..1ea88a8c6717a203bc2f6b2aa4e9c2c5fc16f5e7 100644 (file)
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -2309,15 +2309,11 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
 
    <note>
     <para>
-     Before <productname>PostgreSQL</productname> 8.3, these functions would
-     silently accept values of several non-string data types as well, due to
-     the presence of implicit coercions from those data types to
-     <type>text</type>.  Those coercions have been removed because they frequently
-     caused surprising behaviors.  However, the string concatenation operator
-     (<literal>||</literal>) still accepts non-string input, so long as at least one
-     input is of a string type, as shown in <xref
-     linkend="functions-string-sql"/>.  For other cases, insert an explicit
-     coercion to <type>text</type> if you need to duplicate the previous behavior.
+     The string concatenation operator (<literal>||</literal>) will accept
+     non-string input, so long as at least one input is of string type, as shown
+     in <xref linkend="functions-string-sql"/>.  For other cases, inserting an
+     explicit coercion to <type>text</type> can be used to have non-string input
+     accepted.
     </para>
    </note>
 
@@ -17368,10 +17364,7 @@ SELECT NULLIF(value, '(none)') ...
    (last subscript varies most rapidly).
    If the contents of two arrays are equal but the dimensionality is
    different, the first difference in the dimensionality information
-   determines the sort order.  (This is a change from versions of
-   <productname>PostgreSQL</productname> prior to 8.2: older versions would claim
-   that two arrays with the same contents were equal, even if the
-   number of dimensions or subscript ranges were different.)
+   determines the sort order.
   </para>
 
    <table id="array-operators-table">

diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml
index 67754f52f6499d9125cb3f6f53dea620b94a498c..d68d12d515c2754701efc5f41f1c7dd0c42420ca 100644 (file)
--- a/doc/src/sgml/gin.sgml
+++ b/doc/src/sgml/gin.sgml
@@ -507,7 +507,7 @@
    Updating a <acronym>GIN</acronym> index tends to be slow because of the
    intrinsic nature of inverted indexes: inserting or updating one heap row
    can cause many inserts into the index (one for each key extracted
-   from the indexed item). As of <productname>PostgreSQL</productname> 8.4,
+   from the indexed item).
    <acronym>GIN</acronym> is capable of postponing much of this work by inserting
    new tuples into a temporary, unsorted list of pending entries.
    When the table is vacuumed or autoanalyzed, or when
@@ -576,10 +576,10 @@
     </para>
 
     <para>
-     As of <productname>PostgreSQL</productname> 8.4, this advice is less
-     necessary since delayed indexing is used (see <xref
-     linkend="gin-fast-update"/> for details).  But for very large updates
-     it may still be best to drop and recreate the index.
+     When <literal>fastupdate</literal> is enabled for <acronym>GIN</acronym>
+     (see <xref linkend="gin-fast-update"/> for details), the penalty is
+     less than when it is not.  But for very large updates it may still be
+     best to drop and recreate the index.
     </para>
    </listitem>
   </varlistentry>

diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 472b7cae812bda1eb53bff7b6740df4350ab1bc3..6757033e096b8820e7ef5933f9c00b2fbcd718bc 100644 (file)
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -1934,18 +1934,6 @@ SELECT 2+2;
     by introducing a dummy one-row table from which to do the
     <command>SELECT</command>.
    </para>
-
-   <para>
-    Note that if a <literal>FROM</literal> clause is not specified,
-    the query cannot reference any database tables. For example, the
-    following query is invalid:
-<programlisting>
-SELECT distributors.* WHERE distributors.name = 'Westward';
-</programlisting><productname>PostgreSQL</productname> releases prior to
-    8.1 would accept queries of this form, and add an implicit entry
-    to the query's <literal>FROM</literal> clause for each table
-    referenced by the query. This is no longer allowed.
-   </para>
   </refsect2>
 
   <refsect2>