Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjSMX-0001dQ-IC for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Nov 2020 19:27:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kjSMW-0002qk-Hl for pgsql-hackers@arkaria.postgresql.org; Sun, 29 Nov 2020 19:27:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kjSMW-0002qc-4v for pgsql-hackers@lists.postgresql.org; Sun, 29 Nov 2020 19:27:56 +0000 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kjSMS-0001vJ-RU for pgsql-hackers@postgresql.org; Sun, 29 Nov 2020 19:27:55 +0000 Received: by mail-il1-x12e.google.com with SMTP id g1so9289320ilk.7 for ; Sun, 29 Nov 2020 11:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=cgVFMu/UMVKf+IbJVOS/usJppBqjmdtghUVKsqNsBcU=; b=BxJ8J23zBokGv7gcdK6DnkQB2rqV16zMUyQT/F8AwjSlmfNN8Xs5eiVTbTADEmMyHZ gJJrg9rAOK6jWDTa4o+CbseP24tYy08Iyo2BMu1OkCSgQiygWatuql3D+8jdXQBxG6Na K9csWpOnEBE46pgy8a0OYF8fyCLenr7tUsql8Te8RCqMKa/kAhi/QiXN3bmq/MVskFU2 pGFxbvylqrY7ykHy7QzRT11lBpkuy9sb6G0twJcaa0MvrKfCLgAI6o/uymsFyn4P7+GA B5/lSVHLqbHV9zjbj5/9i2L7slsLGeN7vyIalQrCCtVF38IvAEh4o7Oa2jxelUXnihjg RdXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cgVFMu/UMVKf+IbJVOS/usJppBqjmdtghUVKsqNsBcU=; b=PeVhr6oiTlEWq/93ESfwlM7E71iCgOMbxmVOTQEIYfaw8nY/AXAMJdM7ZxKXV8Zsdv XaDxTXJ9G/FMHJ+BSp0sKNKYI9ZqZvc2nEdAufTdW1dqepSiJMBl4/FGEQb+iL8K3+ba tVlRNUyarZYaMryr2Uq/g8xEqZJBq09NmOcBCAie/dhePDO0UH+sSbCoUNwhqRUnmxuQ w8lM30C2idW0p/S3uOPtPIMccSh06UTRWvbQWSfVDnGtJCDu+vA7rf0nml7v7ZE/DE5f QWMo83mbWIXOwhxUFzi+V0tIsAejyxoVJHH6fYVw9fDJ3rgaB9sXMw+kJVdL5dSm2W6X eTPQ== X-Gm-Message-State: AOAM533f4YAzlYlNkOxGCvSqAhWrVoUNUN7Apw5KtNPdvMG5peiYv1by oa9eDBP3q9h9yxXgFVEiWfierA== X-Google-Smtp-Source: ABdhPJwW+dXSRwnDqkLOVhwaBURWQsoUa3ZtkvTGiuwWm1apa4T0NIMySm6CaEW8UaLrZ/ULo5qf7A== X-Received: by 2002:a92:9f59:: with SMTP id u86mr13041893ili.205.1606678071166; Sun, 29 Nov 2020 11:27:51 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o10sm9870815ili.82.2020.11.29.11.27.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Nov 2020 11:27:50 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id F26268010AF; Sun, 29 Nov 2020 13:27:48 -0600 (CST) Date: Sun, 29 Nov 2020 13:27:48 -0600 From: Justin Pryzby To: Heikki Linnakangas Cc: Tom Lane , Stephen Frost , Ian Lawrence Barwick , pgsql-hackers Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour Message-ID: <20201129192748.GP24052@telsasoft.com> References: <20201023134611.GG16415@tamriel.snowman.net> <145522.1603461363@sss.pgh.pa.us> <20201023141211.GH16415@tamriel.snowman.net> <147812.1603464663@sss.pgh.pa.us> <20201025215650.GN9241@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1ppIqr1kl39GnwQx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --1ppIqr1kl39GnwQx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 26, 2020 at 09:18:00AM +0200, Heikki Linnakangas wrote: > On 25/10/2020 23:56, Justin Pryzby wrote: > > On Fri, Oct 23, 2020 at 11:09:26PM +0300, Heikki Linnakangas wrote: > > > Findings in detail follow. > > > > Are you working on a patch for these ? > > I pushed the patch I included in that email now, to remove the most clear > cases. I'm not planning to do anything more right now. > > > Otherwise, since I started something similar in April, I could put something > > together based on comments you've gotten here. > > That'd be great, thanks! Some docs that Stephen, Heikki, and Yaroslov propoosed to change. -- Justin --1ppIqr1kl39GnwQx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-from-Heikki.patch" From b5660e1c1cd799a38490c7667257193f4d630734 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Sun, 29 Nov 2020 13:12:45 -0600 Subject: [PATCH 1/3] from Heikki --- doc/src/sgml/catalogs.sgml | 1 - doc/src/sgml/config.sgml | 2 +- doc/src/sgml/func.sgml | 5 +---- doc/src/sgml/lobj.sgml | 2 +- doc/src/sgml/protocol.sgml | 2 +- doc/src/sgml/ref/cluster.sgml | 9 --------- 6 files changed, 4 insertions(+), 17 deletions(-) diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 569841398b..238af2fed8 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -10112,7 +10112,6 @@ SCRAM-SHA-256$<iteration count>:&l - diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5b7e91c701..79201376c7 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -9440,7 +9440,7 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir' activity of scans already in progress. This can result in unpredictable changes in the row ordering returned by queries that have no ORDER BY clause. Setting this parameter to - off ensures the pre-8.3 behavior in which a sequential + off ensures the simple behavior in which a sequential scan always starts from the beginning of the table. The default is on. diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 507bc1a668..5c27cc2b13 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -17368,10 +17368,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/lobj.sgml b/doc/src/sgml/lobj.sgml index 6329cf0796..8780458020 100644 --- a/doc/src/sgml/lobj.sgml +++ b/doc/src/sgml/lobj.sgml @@ -144,7 +144,7 @@ Oid lo_creat(PGconn *conn, int mode); or InvalidOid (zero) on failure. mode is unused and - ignored as of PostgreSQL 8.1; however, for + ignored since PostgreSQL 8.1; however, for backward compatibility with earlier releases it is best to set it to INV_READ, INV_WRITE, or INV_READ|INV_WRITE. diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml index cee28889e1..e96ddefa98 100644 --- a/doc/src/sgml/protocol.sgml +++ b/doc/src/sgml/protocol.sgml @@ -172,7 +172,7 @@ Data of a particular data type might be transmitted in any of several - different formats. As of PostgreSQL 7.4 + different formats. Currently the only supported formats are text and binary, but the protocol makes provision for future extensions. The desired format for any value is specified by a format code. diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml index b9450e7366..16e16f6f66 100644 --- a/doc/src/sgml/ref/cluster.sgml +++ b/doc/src/sgml/ref/cluster.sgml @@ -206,15 +206,6 @@ CLUSTER; There is no CLUSTER statement in the SQL standard. - - - The syntax - -CLUSTER index_name ON table_name - - is also supported for compatibility with pre-8.3 PostgreSQL - versions. - -- 2.17.0 --1ppIqr1kl39GnwQx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0002-from-stephen.patch" From 0b500eb54ab4735fc52c15f128a8723e1ca13d4f Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Mon, 26 Oct 2020 16:26:07 -0500 Subject: [PATCH 2/3] from stephen --- doc/src/sgml/func.sgml | 14 +++++--------- doc/src/sgml/gin.sgml | 19 ++++++++----------- 2 files changed, 13 insertions(+), 20 deletions(-) diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 5c27cc2b13..1ea88a8c67 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. diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml index 67754f52f6..cfbb1e0761 100644 --- a/doc/src/sgml/gin.sgml +++ b/doc/src/sgml/gin.sgml @@ -569,17 +569,14 @@ Create vs. insert - Insertion into a GIN index can be slow - due to the likelihood of many keys being inserted for each item. - So, for bulk insertions into a table it is advisable to drop the GIN - index and recreate it after finishing bulk insertion. - - - - 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. + Building a GIN index after all of the data has been + loaded will typically be faster than creating the index and then filling + it. There may also be cases where, for a sufficiently large update, + dropping the GIN index, then performing the update, + and then recreating the index will be faster than a routine update, + however, one should review the delayed indexing technique used for + GIN (see for + details) and the options it provides. -- 2.17.0 --1ppIqr1kl39GnwQx Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0003-Remove-references-to-old-server-behavior.patch" From c6691eb3a21095f7068d6c606d88b95054697d59 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Sun, 29 Nov 2020 13:03:16 -0600 Subject: [PATCH 3/3] Remove references to old server behavior.. From Yaroslov: https://www.postgresql.org/message-id/1599765595731-0.post%40n3.nabble.com --- doc/src/sgml/gin.sgml | 10 +--------- doc/src/sgml/manage-ag.sgml | 5 +---- doc/src/sgml/ref/select.sgml | 26 -------------------------- doc/src/sgml/xfunc.sgml | 8 -------- 4 files changed, 2 insertions(+), 47 deletions(-) diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgml index cfbb1e0761..affdec0eed 100644 --- a/doc/src/sgml/gin.sgml +++ b/doc/src/sgml/gin.sgml @@ -477,14 +477,6 @@ these components of a GIN index. - - As of PostgreSQL 9.1, null key values can be - included in the index. Also, placeholder nulls are included in the index - for indexed items that are null or contain no keys according to - extractValue. This allows searches that should find empty - items to do so. - - Multicolumn GIN indexes are implemented by building a single B-tree over composite values (column number, key value). The @@ -507,7 +499,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 diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgml index 74055a4706..1a127b7df1 100644 --- a/doc/src/sgml/manage-ag.sgml +++ b/doc/src/sgml/manage-ag.sgml @@ -536,10 +536,7 @@ SELECT spcname FROM pg_tablespace; point to each of the non-built-in tablespaces defined in the cluster. Although not recommended, it is possible to adjust the tablespace layout by hand by redefining these links. Under no circumstances perform - this operation while the server is running. Note that in PostgreSQL 9.1 - and earlier you will also need to update the pg_tablespace - catalog with the new locations. (If you do not, pg_dump will - continue to output the old tablespace locations.) + this operation while the server is running. diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index 472b7cae81..1b6e019fa2 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -1604,20 +1604,6 @@ SELECT * FROM (SELECT * FROM mytable FOR UPDATE) ss WHERE col1 = 5; condition is not textually within the sub-query. - - Previous releases failed to preserve a lock which is upgraded by a later - savepoint. For example, this code: - -BEGIN; -SELECT * FROM mytable WHERE key = 1 FOR UPDATE; -SAVEPOINT s; -UPDATE mytable SET ... WHERE key = 1; -ROLLBACK TO s; - - would fail to preserve the FOR UPDATE lock after the - ROLLBACK TO. This has been fixed in release 9.3. - - It is possible for a SELECT command running at the READ @@ -1934,18 +1920,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. - diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 2863f7c206..8f1e5f5e0b 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -275,14 +275,6 @@ but this will not work: INSERT INTO $1 VALUES (42); - - - - The ability to use names to reference SQL function arguments was added - in PostgreSQL 9.2. Functions to be used in - older servers must use the $n notation. - - -- 2.17.0 --1ppIqr1kl39GnwQx--