From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: cataloguing NOT NULL constraints
Date: Fri, 28 Jul 2023 12:47:44 +0200
Message-ID: <20230728104744.wvolubqxph3ag5hh@alvherre.pgsql> (raw)
In-Reply-To: <20230726134939.2zdmokgjwqsiknum@alvherre.pgsql>
> > Given the following sequence:
> >
> > drop table if exists p,c;
> > create table p(a int primary key);
> > create table c() inherits (p);
> > alter table p drop constraint p_pkey;
> > However, c.a remains non-nullable, with a NOT NULL constraint that
> > claims to be inherited:
> >
> > \d+ c
> > Table "public.c"
> > Column | Type | Collation | Nullable | Default | Storage |
> > Compression | Stats target | Description
> > --------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
> > a | integer | | not null | | plain |
> > | |
> > Not null constraints:
> > "c_a_not_null" NOT NULL "a" (inherited)
> > Inherits: p
> > Access method: heap
> >
> > That's a problem, because now the NOT NULL constraint on c cannot be
> > dropped (attempting to drop it on c errors out because it thinks it's
> > inherited, but it can't be dropped via p, because p.a is already
> > nullable).
So I implemented a fix for this (namely: fix the inhcount to be 0
initially), and it works well, but it does cause a definitional problem:
any time we create a child table that inherits from another table that
has a primary key, all the columns in the child table will get normal,
visible, droppable NOT NULL constraints. Thus, pg_dump for example will
output that constraint exactly as if the user had specified it in the
child's CREATE TABLE command. By itself this doesn't bother me, though
I admit it seems a little odd.
When you restore such a setup from pg_dump, things work perfectly -- I
mean, you don't get a second constraint. But if you do drop the
constraint, then it will be reinstated by the next pg_dump as if you
hadn't dropped it, by way of it springing to life from the PK.
To avoid that, one option would be to make this NN constraint
undroppable ... but I don't see how. One option might be to add a
pg_depend row that links the NOT NULL constraint to its PK constraint.
But this will be a strange case that occurs nowhere else, since other
NOT NULL constraint don't have such pg_depend rows. Also, I won't know
how pg_dump likes this until I implement it.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: alvherre@alvh.no-ip.org, dean.a.rasheed@gmail.com, robertmhaas@gmail.com, peter@eisentraut.org, pgsql-hackers@lists.postgresql.org
Subject: Re: cataloguing NOT NULL constraints
In-Reply-To: <20230728104744.wvolubqxph3ag5hh@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox