Feedback-ID: ie3de48e3:Fastmail
Date: Mon, 6 Oct 2025 12:44:28 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, andrewbille@gmail.com,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the
 inherited table field when dumping v17-databases
Message-ID: <202510061043.hjzm5ixk5tfs@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAFiTN-stWLizPYn9DGiL+7uhdrWNebuXRK1Hg+uvgH34uqCMfg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202510061043.hjzm5ixk5tfs%40alvherre.pgsql>
Precedence: bulk

On 2025-Oct-06, Dilip Kumar wrote:

> 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.

Ah, right, the column is indeed not local, but the constraint is.  I
think this means we need to use flagInhAttrs to require the constraint
to be printed ... looking.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/