| From: | Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: persevere NO INHERIT when Dump not-null constraints on inherited columns |
| Date: | 2026-02-26 12:23:49 |
| Message-ID: | 202602261221.qjabdj3zsokq@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Feb-26, Ashutosh Bapat wrote:
> This could have been caught by 002_pg_upgrade's regression
> dump/restore test, if we had a NO INHERIT on child being tested in
> regression test and not dropped. I browsed through regression tests
> testing NO INHERIT. I found some adding NO INHERIT check constraint on
> child table but no NOT NULL constraint on child table. But I didn't
> look very closely. If that's true, we may not have enough coverage to
> check whether NO INHERIT on a child table is honoured or not when a
> grandchild is added. I did find a test which tests that NO INHERIT NOT
> NULL on the child table is not merged with normal NOT NULL constraint.
Hmm, yeah, feel free to propose a change so that those tables are not
dropped, so that this is exercised better in the
PG_TEST_EXTRA=regress_dump_restore case. I guess the whole gamut of
NOT ENFORCED, NOT VALID etc ought to be covered that way.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-02-26 12:35:35 | Re: Having problems generating a code coverage report |
| Previous Message | Nazir Bilal Yavuz | 2026-02-26 12:19:32 | Re: Speed up COPY FROM text/CSV parsing using SIMD |