From: Justin Pryzby <pryzby@telsasoft.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Ian Lawrence Barwick <barwick@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour
Date: Sun, 29 Nov 2020 13:27:48 -0600
Message-ID: <20201129192748.GP24052@telsasoft.com> (raw)
In-Reply-To: <ca583d26-6bcf-6081-dc72-f1fcf867e974@iki.fi>
References: <CAB8KJ=jYHgnxLLZSNJz7gBTck4TxomngCmGkw3nEMSNF0yL6wA@mail.gmail.com>
<CAB8KJ=h-XALik4M7gv-pX48=+SPWexfaYwa+yTnPwD3DxceXrg@mail.gmail.com>
<e4934710-73cb-6eef-fd35-6fcfd05f381b@iki.fi>
<20201023134611.GG16415@tamriel.snowman.net>
<145522.1603461363@sss.pgh.pa.us>
<20201023141211.GH16415@tamriel.snowman.net>
<147812.1603464663@sss.pgh.pa.us>
<fd93f1c5-7818-a02c-01e5-1075ac0d4def@iki.fi>
<20201025215650.GN9241@telsasoft.com>
<ca583d26-6bcf-6081-dc72-f1fcf867e974@iki.fi>
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
Attachments:
[text/x-diff] 0001-from-Heikki.patch (4.3K, ../20201129192748.GP24052@telsasoft.com/2-0001-from-Heikki.patch)
download | inline diff:
From b5660e1c1cd799a38490c7667257193f4d630734 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
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.sgmlindex 569841398b..238af2fed8 100644--- a/doc/src/sgml/catalogs.sgml+++ b/doc/src/sgml/catalogs.sgml@@ -10112,7 +10112,6 @@ SCRAM-SHA-256$<replaceable><iteration count></replaceable>:<replaceable>&l
</tbody>
</tgroup>
</table>
-
</sect1>
<sect1 id="view-pg-hba-file-rules">
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgmlindex 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 <literal>ORDER BY</literal> clause. Setting this parameter to
- <literal>off</literal> ensures the pre-8.3 behavior in which a sequential+ <literal>off</literal> ensures the simple behavior in which a sequential
scan always starts from the beginning of the table. The default
is <literal>on</literal>.
</para>
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgmlindex 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- <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/lobj.sgml b/doc/src/sgml/lobj.sgmlindex 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 <symbol>InvalidOid</symbol> (zero) on failure.
<replaceable class="parameter">mode</replaceable> is unused and
- ignored as of <productname>PostgreSQL</productname> 8.1; however, for+ ignored since <productname>PostgreSQL</productname> 8.1; however, for
backward compatibility with earlier releases it is best to
set it to <symbol>INV_READ</symbol>, <symbol>INV_WRITE</symbol>,
or <symbol>INV_READ</symbol> <literal>|</literal> <symbol>INV_WRITE</symbol>.
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgmlindex cee28889e1..e96ddefa98 100644--- a/doc/src/sgml/protocol.sgml+++ b/doc/src/sgml/protocol.sgml@@ -172,7 +172,7 @@
<para>
Data of a particular data type might be transmitted in any of several
- different <firstterm>formats</firstterm>. As of <productname>PostgreSQL</productname> 7.4+ different <firstterm>formats</firstterm>. Currently
the only supported formats are <quote>text</quote> and <quote>binary</quote>,
but the protocol makes provision for future extensions. The desired
format for any value is specified by a <firstterm>format code</firstterm>.
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgmlindex b9450e7366..16e16f6f66 100644--- a/doc/src/sgml/ref/cluster.sgml+++ b/doc/src/sgml/ref/cluster.sgml@@ -206,15 +206,6 @@ CLUSTER;
<para>
There is no <command>CLUSTER</command> statement in the SQL standard.
</para>
-- <para>- The syntax-<synopsis>-CLUSTER <replaceable class="parameter">index_name</replaceable> ON <replaceable class="parameter">table_name</replaceable>-</synopsis>- is also supported for compatibility with pre-8.3 <productname>PostgreSQL</productname>- versions.- </para>
</refsect1>
<refsect1>
--
2.17.0
[text/x-diff] 0002-from-stephen.patch (3.0K, ../20201129192748.GP24052@telsasoft.com/3-0002-from-stephen.patch)
download | inline diff:
From 0b500eb54ab4735fc52c15f128a8723e1ca13d4f Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
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.sgmlindex 5c27cc2b13..1ea88a8c67 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>
diff --git a/doc/src/sgml/gin.sgml b/doc/src/sgml/gin.sgmlindex 67754f52f6..cfbb1e0761 100644--- a/doc/src/sgml/gin.sgml+++ b/doc/src/sgml/gin.sgml@@ -569,17 +569,14 @@
<term>Create vs. insert</term>
<listitem>
<para>
- Insertion into a <acronym>GIN</acronym> 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.- </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.+ Building a <acronym>GIN</acronym> 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 <acronym>GIN</acronym> 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+ <acronym>GIN</acronym> (see <xref linkend="gin-fast-update"/> for+ details) and the options it provides.
</para>
</listitem>
</varlistentry>
--
2.17.0
[text/x-diff] 0003-Remove-references-to-old-server-behavior.patch (4.8K, ../20201129192748.GP24052@telsasoft.com/4-0003-Remove-references-to-old-server-behavior.patch)
download | inline diff:
From c6691eb3a21095f7068d6c606d88b95054697d59 Mon Sep 17 00:00:00 2001
From: Justin Pryzby <pryzbyj@telsasoft.com>
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.sgmlindex 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.
</para>
- <para>- As of <productname>PostgreSQL</productname> 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- <function>extractValue</function>. This allows searches that should find empty- items to do so.- </para>-
<para>
Multicolumn <acronym>GIN</acronym> indexes are implemented by building
a single B-tree over composite values (column number, key value). The
@@ -507,7 +499,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
diff --git a/doc/src/sgml/manage-ag.sgml b/doc/src/sgml/manage-ag.sgmlindex 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 <structname>pg_tablespace</structname>- catalog with the new locations. (If you do not, <literal>pg_dump</literal> will- continue to output the old tablespace locations.)+ this operation while the server is running.
</para>
</sect1>
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgmlindex 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.
</para>
- <para>- Previous releases failed to preserve a lock which is upgraded by a later- savepoint. For example, this code:-<programlisting>-BEGIN;-SELECT * FROM mytable WHERE key = 1 FOR UPDATE;-SAVEPOINT s;-UPDATE mytable SET ... WHERE key = 1;-ROLLBACK TO s;-</programlisting>- would fail to preserve the <literal>FOR UPDATE</literal> lock after the- <command>ROLLBACK TO</command>. This has been fixed in release 9.3.- </para>-
<caution>
<para>
It is possible for a <command>SELECT</command> command running at the <literal>READ
@@ -1934,18 +1920,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>
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgmlindex 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);
</programlisting>
</para>
-- <note>- <para>- The ability to use names to reference SQL function arguments was added- in <productname>PostgreSQL</productname> 9.2. Functions to be used in- older servers must use the <literal>$<replaceable>n</replaceable></literal> notation.- </para>- </note>
</sect2>
<sect2 id="xfunc-sql-base-functions">
--
2.17.0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, hlinnaka@iki.fi, tgl@sss.pgh.pa.us, sfrost@snowman.net, barwick@gmail.com
Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour
In-Reply-To: <20201129192748.GP24052@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox