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

3 files changed, 11 insertions, 30 deletions

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 507bc1a6683..1ea88a8c671 100644
--- 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 67754f52f64..d68d12d515c 100644
--- 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 472b7cae812..6757033e096 100644
--- 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>