Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Date: 2025-04-28 14:50:35
Message-ID: 202504281450.4powv4cchler@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-Apr-26, jian he wrote:

> I am wondering if we need to change the following comments in getTableAttrs.
>
> * We track in notnull_islocal whether the constraint was defined directly
> * in this table or via an ancestor, for binary upgrade. flagInhAttrs
> * might modify this later for servers older than 18; it's also in charge
> * of determining the correct inhcount.
> since we also changed notnull_islocal for pg18.

Yeah.

> Also do we need to adjust the following comments in determineNotNullFlags?
> * In a child table that inherits from a parent already containing NOT NULL
> * constraints and the columns in the child don't have their own NOT NULL
> * declarations, we suppress printing constraints in the child: the
> * constraints are acquired at the point where the child is attached to the
> * parent. This is tracked in ->notnull_islocal (which is set in flagInhAttrs
> * for servers pre-18).

Adjusted this one as well.

I also fixed the business with multiple inheritance: with the commit I
just pushed, we stop printing the child constraint if at least one
parent has a validated constraint.

With that, I believe this open item is closed, so I'm going to mark it
as such in the wiki page momentarily.

> > Patch 0002 is a part of your proposed patch that I don't think we need,
> > but I'm open to hearing arguments about why we do, preferrably with some
> > test cases.
>
> ------------
> CREATE TABLE inhnn (a int);
> insert into inhnn values(NULL);
> ALTER TABLE inhnn ADD CONSTRAINT cc not null a NOT VALID;
> CREATE TABLE inhnn_cc(a INTEGER) INHERITS(inhnn);
> CREATE TABLE inhnn_cc_1(a INTEGER) INHERITS(inhnn_cc, inhnn);
> --------

> As you can see, "conislocal" is not consistent, maybe in practical it
> does not matter,
> but here we can make pg_dump, "conislocal" value being consistent.

Yeah, I realize that this effect exists, but I find it very hard to
justify spending time on this issue given that there are no visible
consequences. What I can offer is that if you come up with a test setup
that fails when this patch is not applied, and works when it is applied,
then I'm open to considering it.

--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-04-28 15:15:05 Re: optimize file transfer in pg_upgrade
Previous Message Robert Haas 2025-04-28 14:50:13 Re: ZStandard (with dictionaries) compression support for TOAST compression