Thread: Re: pgsql: Set the volatility of the timestamptz version of date_bin() back
Re: pgsql: Set the volatility of the timestamptz version of date_bin() back
From
Alvaro Herrera
Date:
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 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.
--
John Naylor
EDB: http://www.enterprisedb.com
Re: pgsql: Set the volatility of the timestamptz version of date_bin() back
From
Alvaro Herrera
Date:
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