From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <john.naylor@postgresql.org>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Set the volatility of the timestamptz version of
 date_bin() back
In-reply-to: <E1mMDCu-0008Pf-Dv@gemulon.postgresql.org>
References: <E1mMDCu-0008Pf-Dv@gemulon.postgresql.org>
Comments: In-reply-to John Naylor <john.naylor@postgresql.org>
	message dated "Fri, 03 Sep 2021 17:42:28 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2598258.1630701778.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 03 Sep 2021 16:42:58 -0400
Message-ID: <2598260.1630701778@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2598260.1630701778%40sss.pgh.pa.us>
Precedence: bulk

John Naylor <john.naylor@postgresql.org> writes:
> Set the volatility of the timestamptz version of date_bin() back to immu=
table
> 543f36b43d was too hasty in thinking that the volatility of date_bin()
> had to match date_trunc(), since only the latter references
> session_timezone.

> Bump catversion

What you should have done here, at least in the back branch, was *revert*
catversion to what it had been.  As things stand, it would force users of
14beta3 to initdb or pg_upgrade to move to 14.0, for no reason whatsoever.

			regards, tom lane