Re: BUG #19074: pg_dump from v18 loses the NOT NULL flag in the inherited table field when dumping v17-databases

On Mon, Oct 6, 2025 at 4:14 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
>
> 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.
>

I think we can fix it in getTableAttrs(), see attached, with that I
can see my dump is correct.  This is just a quick way to show what I
am thinking, maybe we can improve this condition.  I believe
flagInhAttrs() is more about resetting the "notnull_islocal" if any of
the parent already has it as non null.  This fix is working with this
basic case, but I haven't investigated whether it will work in all
cases or is it breaking anything.

After this fix the dump look like this

CREATE TABLE public.p (
    a integer
);


ALTER TABLE public.p OWNER TO dilipkumarb;

--
-- Name: c; Type: TABLE; Schema: public; Owner: dilipkumarb
--

CREATE TABLE public.c (
    NOT NULL a        -- now after fix NOT NULL constraint is added in the dump
)
INHERITS (public.p);


--
Regards,
Dilip Kumar
Google