Horton

Re: Support for NO INHERIT to INHERIT state change with named NOT NULL constraints

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Suraj Kharage <suraj.kharage@enterprisedb.com>
Cc: jian he <jian.universality@gmail.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-01-08T09:13:22Z
Lists: pgsql-hackers 
On 2024-Nov-25, Suraj Kharage wrote:

> Another case which needs conclusion is -
> When changing from INHERIT to NO INHERIT, we need to walk all children and
> decrement coninhcount for the corresponding constraint. If a constraint in
> one child reaches zero, should we drop it?  not sure. If we do, make sure
> to reset the corresponding attnotnull bit too. We could decide not to drop
> the constraint, in which case you don’t need to reset attnotnull.

I think it's more useful if we keep such a constraint (but of course
change its conislocal to true, if it isn't that already).

There are arguments for doing both things (drop it or leave it); but if
you drop it, there's no way to put it back without scanning the table
again.  If you keep it, it's easy to drop it afterwards.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Postgres is bloatware by design: it was built to house
 PhD theses." (Joey Hellerstein, SIGMOD annual conference 2002)

Commits

  1. Small fixes for Add ALTER TABLE ... ALTER CONSTRAINT ... SET [NO] INHERIT

  2. Add ALTER TABLE ... ALTER CONSTRAINT ... SET [NO] INHERIT

  3. Add pg_constraint rows for not-null constraints