| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Missing update of all_hasnulls in BRIN opclasses |
| Date: | 2023-04-24 21:10:50 |
| Message-ID: | 546688.1682370650@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2023-04-24 21:10:55 | Re: Missing update of all_hasnulls in BRIN opclasses |
| Previous Message | Tomas Vondra | 2023-04-24 21:05:23 | Re: Missing update of all_hasnulls in BRIN opclasses |