Date: Fri, 3 Sep 2021 13:27:25 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: John Naylor <john.naylor@enterprisedb.com>,
	John Naylor <john.naylor@postgresql.org>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Set the volatility of the timestamptz version of
 date_bin() back
Message-ID: <20210903182725.GZ26465@telsasoft.com>
References: 
 <CAFBsxsFB2OFLgaiwCR-3Tbb3nD16OXMwnqSC+2d_0Ze=p4qm1w@mail.gmail.com>
 <202109031756.d6li4szj5zje@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202109031756.d6li4szj5zje@alvherre.pgsql>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210903182725.GZ26465%40telsasoft.com>
Precedence: bulk

On Fri, Sep 03, 2021 at 01:56:50PM -0400, Alvaro Herrera wrote:
> On 2021-Sep-03, John Naylor wrote:
> 
> > On Fri, Sep 3, 2021 at 1:46 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
> > wrote:
> > >
> > > On 2021-Sep-03, John Naylor wrote:
> > > These catversion bumps in branch 14 this late in the cycle seem suspect.
> > > Didn't we have some hesitation to push multirange unnest around beta2
> > > precisely because of a desire to avoid catversion bumps?
> > 
> > This was for correcting a mistake (although the first commit turned out to
> > be a mistake itself), so I understood it to be necessary.
> 
> A crazy idea might have been to return to the original value.

+1.  I think the catversion usually is always increased even in a "revert", but
in this exceptional case [0] it would be nice if beta4/rc1 had the same number
as b3.

[0] two commits close to each other, with no other catalog changes, and with
the specific goal of allowing trivial upgrade from b3.

-- 
Justin