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.
