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 <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1kW9Lw-0004h3-94
	for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Oct 2020 02:32:20 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1kW9LO-0007ZW-MJ
	for pgsql-hackers@arkaria.postgresql.org; Sat, 24 Oct 2020 02:31:46 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kW9LO-0007ZO-Fc
	for pgsql-hackers@lists.postgresql.org; Sat, 24 Oct 2020 02:31:46 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1kW9LH-0003kG-V9
	for pgsql-hackers@postgresql.org; Sat, 24 Oct 2020 02:31:45 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 09O2VXaY333274;
	Fri, 23 Oct 2020 22:31:34 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
cc: Stephen Frost <sfrost@snowman.net>,
        Ian Lawrence Barwick <barwick@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour
In-reply-to: <fd93f1c5-7818-a02c-01e5-1075ac0d4def@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>
Comments: In-reply-to Heikki Linnakangas <hlinnaka@iki.fi>
	message dated "Fri, 23 Oct 2020 23:09:26 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <333271.1603506693.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 23 Oct 2020 22:31:33 -0400
Message-ID: <333272.1603506693@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 23/10/2020 17:51, Tom Lane wrote:
>> Seems like we could have gotten rid of that by now, but when exactly
>> does it become fair game?  And can we have a non-ad-hoc process for
>> getting rid of such cruft?

> I did some grepping for strings like "version 7", "pre-8" and so on. I =

> couldn't come up with a clear rule on what could be removed. Context =

> matters.

Yeah, that's unsurprising.  But thanks for all the effort you put into
this review!

> Findings in detail follow. And attached is a patch about the stuff that =

> I think can be removed pretty straightforwardly.

I agree with the patch, and with your other thoughts, except as noted
below.

> config.sgml (on synchronized_scans):

>          have no <literal>ORDER BY</literal> clause.  Setting this param=
eter to
>          <literal>off</literal> ensures the pre-8.3 behavior in which a =
sequential
>          scan always starts from the beginning of the table.  The defaul=
t
>          is <literal>on</literal>.

> We could remove the reference to 8.3 version. I'm inclined to keep it =

> though.

Maybe s/pre-8.3/simple/, or some similar adjective?

> func.sgml:
>     <note>
>       <para>
>       Before <productname>PostgreSQL</productname> 8.2, the containment
>       operators <literal>@&gt;</literal> and <literal>&lt;@</literal> =

> were respectively
>       called <literal>~</literal> and <literal>@</literal>.  These names=
 =

> are still
>       available, but are deprecated and will eventually be removed.
>      </para>
>     </note>

> The old names are still available, so should keep this.

Perhaps it's time to actually remove those operators as threatened here?
That's material for a separate discussion, though.

>     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.)
>    </para>

> Could remove it.

Yeah, I'm OK with removing the parenthetical comment.

>       There are two differences in the behavior of <function>string_to_a=
rray</function>
>       from pre-9.1 versions of <productname>PostgreSQL</productname>.

> Feels too early to remove.

+1.  9.1 was in support till ~4 years ago; 8.2 EOL'd 9 years ago.
I'm not sure where to put the cutoff, but 4 years seems too little.

>    <note>
>     <para>
>      Prior to <productname>PostgreSQL</productname> 8.2, the
>      <literal>&lt;</literal>, <literal>&lt;=3D</literal>, =

> <literal>&gt;</literal> and <literal>&gt;=3D</literal>
>      cases were not handled per SQL specification.  A comparison like
>      <literal>ROW(a,b) &lt; ROW(c,d)</literal>
>      was implemented as
>      <literal>a &lt; c AND b &lt; d</literal>
>      whereas the correct behavior is equivalent to
>      <literal>a &lt; c OR (a =3D c AND b &lt; d)</literal>.
>     </para>
>    </note>

> Important incompatibility. Although very old. I'm inclined to keep it. =

> If we remove it, it'd still be useful to explain the new behavior.

Yeah, even if we don't care about 8.2, some of this text is useful
to clarify the behavior of row comparisons.  I haven't looked at
the surrounding material, but I'd not want to just delete this
unless it's clearly duplicative.

>       As of <productname>PostgreSQL</productname> 8.4, this advice is le=
ss
>       necessary since delayed indexing is used (see <xref
>       linkend=3D"gin-fast-update"/> for details).  But for very large up=
dates
>       it may still be best to drop and recreate the index.

> I think that's old enough, but the paragraph would need some =

> copy-editing, not just removal.

Right, same deal, needs a bit of wordsmithing not just deletion.

>       <replaceable class=3D"parameter">mode</replaceable> is unused and
>       ignored as of <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>.

> We need to say something about 'mode'. Keep.

Maybe s/as of/since/, but otherwise fine.

>      Data of a particular data type might be transmitted in any of sever=
al
>      different <firstterm>formats</firstterm>.  As of =

> <productname>PostgreSQL</productname> 7.4
>      the only supported formats are <quote>text</quote> and =

> <quote>binary</quote>,
>      but the protocol makes provision for future extensions.  The desire=
d

> Could replace the "as of PostgreSQL 7.4" with "Currently", but it's not =

> much shorter.

While it's not shorter, I think it's clearer in this context.  7.4
is far enough back that a reader might expect the next sentence to
offer updated info.

>     <!-- TODO we need to put a date on these numbers? -->
>    <para>
>     Another example &mdash; the <productname>PostgreSQL</productname> =

> mailing
>     list archives contained 910,989 unique words with 57,491,343 lexemes=
 in
>     461,020 messages.
>    </para>

> Refresh the numbers.

I agree with the comment: if we keep this, there should be an "as of" date
associated with the numbers.

Thanks again for slogging through that!

			regards, tom lane