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.
