Horton

Re: Missing update of all_hasnulls in BRIN opclasses

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Justin Pryzby <pryzby@telsasoft.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-04-24T21:10:50Z
Lists: pgsql-hackers 
Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> On 4/24/23 17:46, Tom Lane wrote:
>> "A bit laborious"?  That seems enormously out of proportion to the
>> benefit of putting this test case into back branches.  It will have
>> costs for end users too, not only us.  As an example, it would
>> unecessarily block some upgrade paths, if the upgraded-to installation
>> is slightly older and lacks the necessary --1.X.1--1.12 script.

> Why would that block the upgrade? Presumably we'd add two upgrade
> scripts in the master, to allow upgrade both from 1.X and 1.X.1.

It would for example block updating from 14.8 or later to 15.2, since
a 15.2 installation would not have the script to update from 1.X.1.

Yeah, people could work around that by only installing the latest
version, but there are plenty of real-world scenarios where you'd be
creating friction, or at least confusion.  I do not think that this
test case is worth it.

			regards, tom lane

Commits

  1. Show empty BRIN ranges in brin_page_items

  2. Fix handling of empty ranges and NULLs in BRIN

  3. Fix handling of NULLs when merging BRIN summaries

  4. Move IS [NOT] NULL handling from BRIN support functions