Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: andrewbille@gmail.com, pgsql-bugs@lists.postgresql.org, Álvaro Herrera <alvherre@kurilemu.de>
Date: 2025-10-06T06:49:41Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix determination of not-null constraint "locality" for inherited columns
- c945b06d5f03 17.7 landed
- 615ff828e1cb 19 (unreleased) landed
- 0fe07fa115f5 18.1 landed
-
Fix pg_dump sorting of foreign key constraints
- d20df9590aef 13.23 landed
- 7419c99a25fb 17.7 landed
- 6062c3db3093 14.20 landed
- 4cc3b4445913 15.15 landed
- 4921a5972a34 19 (unreleased) landed
- 162e70ea06eb 18.1 landed
- 06c1ee6b75dc 16.11 landed
-
Sort dump objects independent of OIDs, for the 7 holdout object types.
- 0decd5e89db9 19 (unreleased) cited
-
Add pg_constraint rows for not-null constraints
- 14e87ffa5c54 18.0 cited
On Mon, Oct 6, 2025 at 11:52 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Mon, Oct 6, 2025 at 9:29 AM David Rowley <dgrowleyml@gmail.com> wrote: > > > > On Mon, 6 Oct 2025 at 16:42, Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > I tried to reproduce this, but here is what I see[1] when I dump in > > > REL_18_STABLE, I noticed that "NOT NULL a" for inherited tables is > > > included along with the create table statement itself, so this doesn't > > > seems like an issue, am I missing something? > > > > I think so. I believe the intent was to convey the server version is > > 17.6 and the pg_dump version is 18.0, in which case, there does appear > > to be a problem. > > > > Yeah you are right, while checking the git log, it seems it got broken > in this commit [1]. So I just tested on the previous commit and it > was working fine but got broken on this commit. Adding Alvaro as he > has committed this. > > [1] > commit 14e87ffa5c543b5f30ead7413084c25f7735039f > Author: Álvaro Herrera <alvherre@alvh.no-ip.org> > Date: Fri Nov 8 13:28:48 2024 +0100 > Add pg_constraint rows for not-null constraints While quickly checking this commit, it seems the problem is that before this commit we had a simple logic to add an additional ALTER TABLE to SET NULL, if the attribute has a not null constraint but the the parent from which it is inherited doesn't have not null constraint [1]. Whereas after this commit, it seems we removed this ALTER command and tried to add the not null constraint while creating the inherited table itself, which is fine. But here the logic to identify whether the constraint is local or not for v17 is not correct [2], it sets "notnull_islocal", only if the "attislocal" is true, which seems to be wrong. Because the test case given in this bug the attribute is not local but it is marked not null. [1] if (!shouldPrintColumn(dopt, tbinfo, j) && tbinfo->notnull[j] && !tbinfo->inhNotNull[j]) appendPQExpBuffer(q, "ALTER %sTABLE ONLY %s ALTER COLUMN %s SET NOT NULL;\n", foreign, qualrelname, fmtId(tbinfo->attnames[j])); [2] if (fout->remoteVersion >= 180000) appendPQExpBufferStr(q, "co.conname AS notnull_name,\n" "CASE WHEN co.convalidated THEN pt.description" " ELSE NULL END AS notnull_comment,\n" "CASE WHEN NOT co.convalidated THEN co.oid " "ELSE NULL END AS notnull_invalidoid,\n" "co.connoinherit AS notnull_noinherit,\n" "co.conislocal AS notnull_islocal,\n"); else appendPQExpBufferStr(q, "CASE WHEN a.attnotnull THEN '' ELSE NULL END AS notnull_name,\n" "NULL AS notnull_comment,\n" "NULL AS notnull_invalidoid,\n" "false AS notnull_noinherit,\n" "a.attislocal AS notnull_islocal,\n"); -- this seems to be problamatic -- Regards, Dilip Kumar Google