From 8a17f44c1e7a9f3d2a9da97dc3eba4184a2a453c Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Tue, 1 Dec 2020 16:32:26 +0900 Subject: [PATCH] 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 --- doc/src/sgml/func.sgml | 19 ++++++------------- doc/src/sgml/gin.sgml | 10 +++++----- doc/src/sgml/ref/select.sgml | 12 ------------ 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) PgPgPgPg - Before PostgreSQL 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 - text. Those coercions have been removed because they frequently - caused surprising behaviors. However, the string concatenation operator - (||) still accepts non-string input, so long as at least one - input is of a string type, as shown in . For other cases, insert an explicit - coercion to text if you need to duplicate the previous behavior. + The string concatenation operator (||) will accept + non-string input, so long as at least one input is of string type, as shown + in . For other cases, inserting an + explicit coercion to text can be used to have non-string input + accepted. @@ -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 - PostgreSQL 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. 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 GIN 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 PostgreSQL 8.4, + from the indexed item). GIN 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 @@ - As of PostgreSQL 8.4, this advice is less - necessary since delayed indexing is used (see for details). But for very large updates - it may still be best to drop and recreate the index. + When fastupdate is enabled for GIN + (see 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. 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 SELECT. - - - Note that if a FROM clause is not specified, - the query cannot reference any database tables. For example, the - following query is invalid: - -SELECT distributors.* WHERE distributors.name = 'Westward'; -PostgreSQL releases prior to - 8.1 would accept queries of this form, and add an implicit entry - to the query's FROM clause for each table - referenced by the query. This is no longer allowed. -