From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg17 issues with not-null contraints |
Date: | 2024-04-18 16:52:02 |
Message-ID: | ZiFPsoYEsCjNwHnk@pryzbyj2023 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 18, 2024 at 06:23:30PM +0200, Alvaro Herrera wrote:
> On 2024-Apr-18, Justin Pryzby wrote:
>
> > BTW, this works up to v16 (although maybe it should not):
> >
> > | CREATE TABLE ip(id int PRIMARY KEY); CREATE TABLE ic(id int) INHERITS (ip); ALTER TABLE ic ALTER id DROP NOT NULL;
>
> > It'd still be nice to detect the issue in advance rather than failing
> > halfway through the upgrade.
>
> Maybe we can have pg_upgrade --check look for cases we might have
> trouble upgrading. (I mean: such cases would fail if you have rows with
> nulls in the affected columns, but the schema upgrade should be
> successful. Is that what you have in mind?)
Before v16, pg_upgrade failed in the middle of restoring the schema,
without being caught during --check. The patch to implement that was
forgotten and never progressed.
I'm not totally clear on what's intended in v17 - maybe it'd be dead
code, and maybe it shouldn't even be applied to master branch. But I do
think it's worth patching earlier versions (even though it'll be less
useful than having done so 5 years ago).
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Dagfinn Ilmari Mannsåker | 2024-04-18 17:03:21 | Re: Add SPLIT PARTITION/MERGE PARTITIONS commands |
Previous Message | Robert Haas | 2024-04-18 16:46:19 | Re: Transparent column encryption |