Обсуждение: Re: pgsql: Set the volatility of the timestamptz version of date_bin() back

On 2021-Sep-03, John Naylor wrote:

> Set the volatility of the timestamptz version of date_bin() back to immutable
> 
> 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

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?

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/

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.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Sep-03, John Naylor wrote:
>> On Fri, Sep 3, 2021 at 1:46 PM Alvaro Herrera <alvherre@alvh.no-ip.org>
>> 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.

Yes, that is what should have been done, as I complained over
in pgsql-committers before seeing this exchange.  As things
stand, a pg_upgrade is going to be forced on beta3 users
without even the excuse of fixing a bug.

            regards, tom lane