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 1kVxYG-0008B8-MQ for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Oct 2020 13:56:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kVxYE-0004UJ-RU for pgsql-hackers@arkaria.postgresql.org; Fri, 23 Oct 2020 13:56:14 +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 1kVxYE-0004UC-Kj for pgsql-hackers@lists.postgresql.org; Fri, 23 Oct 2020 13:56:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kVxYA-0006bY-HA for pgsql-hackers@postgresql.org; Fri, 23 Oct 2020 13:56:14 +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 09NDu3CM145523; Fri, 23 Oct 2020 09:56:03 -0400 From: Tom Lane To: Stephen Frost cc: Heikki Linnakangas , Ian Lawrence Barwick , pgsql-hackers Subject: Re: [doc] remove reference to pg_dump pre-8.1 switch behaviour In-reply-to: <20201023134611.GG16415@tamriel.snowman.net> References: <20201023134611.GG16415@tamriel.snowman.net> Comments: In-reply-to Stephen Frost message dated "Fri, 23 Oct 2020 09:46:11 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <145521.1603461363.1@sss.pgh.pa.us> Date: Fri, 23 Oct 2020 09:56:03 -0400 Message-ID: <145522.1603461363@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Stephen Frost writes: > Isn't this a bit pre-mature as we still support running pg_dump against > 8.0 clusters..? The removed para was discussing the behavior of pg_dump itself. What server version you run it against isn't relevant. Having said that, there are a *lot* of past-their-sell-by-date bits of info throughout our documentation, because we don't have any sort of policy or mechanism for getting rid of this kind of backwards compatibility note. Maybe we should first try to agree on a policy for when it's okay to remove such info. regards, tom lane