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

On Wed, Jan 8, 2025 at 2:43 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

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

Thanks Alvaro.
Please find attached revised version of patch which added the INHERIT to NO
INHERIT state change for not null constraint.
Keep the constraint (instead of dropping) when we mark NO INHERIT.
As Alvaro mentioned above, we can take others opinion on this behavior.
Also, changed the syntax to ALTER TABLE <tabname> ALTER CONSTRAINT
<constrname> SET INHERIT/NO INHERIT;
just to avoid grammer conflicts but we can decide that as well.

Thanks,
Suraj