Re: cataloguing NOT NULL constraints
Laurenz Albe <laurenz.albe@cybertec.at>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Revert structural changes to not-null constraints
- 6f8bb7c1e961 17.0 landed
-
Fix inconsistencies in error messages
- 21ac38f498b3 17.0 landed
-
Disallow direct change of NO INHERIT of not-null constraints
- d45597f72fe5 17.0 landed
-
Disallow NO INHERIT not-null constraints on partitioned tables
- 13daa33fa5a6 17.0 landed
-
Better handle indirect constraint drops
- 0cd711271d42 17.0 cited
-
Don't try to assign smart names to constraints
- d72d32f52d26 17.0 cited
-
Fix restore of not-null constraints with inheritance
- d9f686a72ee9 17.0 landed
-
ATTACH PARTITION: Don't match a PK with a UNIQUE constraint
- cee8db3f680b 17.0 landed
-
Fix propagating attnotnull in multiple inheritance
- c3709100be73 17.0 landed
-
Check stack depth in new recursive functions
- b0f7dd915bca 17.0 landed
-
Move privilege check to the right place
- ac22a9545ca9 17.0 cited
-
Update information_schema definition for not-null constraints
- 3af721794272 17.0 landed
-
Fix not-null constraint test
- d0ec2ddbe088 17.0 landed
-
Disallow changing NO INHERIT status of a not-null constraint
- 9b581c534186 17.0 cited
-
Catalog not-null constraints
- b0e96f311985 17.0 cited
-
parallel_schedule: add comment on event_trigger test dependency
- c8e43c22be27 17.0 landed
-
Revert "Catalog NOT NULL constraints" and fallout
- 9ce04b50e120 16.0 landed
-
Adjust contrib/sepgsql regression test expected outputs.
- 76c111a7f166 16.0 landed
-
Fix table name clash in recently introduced test
- 728015a47016 16.0 landed
-
Catalog NOT NULL constraints
- e056c557aef4 16.0 landed
-
Change the rules for inherited CHECK constraints to be essentially the same
- cd902b331dc4 8.4.0 cited
On Thu, 2022-08-18 at 11:04 +0200, Alvaro Herrera wrote: > On 2022-Aug-18, Laurenz Albe wrote: > > On Wed, 2022-08-17 at 20:12 +0200, Alvaro Herrera wrote: > > > Using ALTER TABLE DROP CONSTRAINT works fine, and the 'attnotnull' > > > bit is lost when the last one such constraint goes away. > > > > Wouldn't it be the correct solution to set "attnotnumm" to FALSE only > > when the last NOT NULL constraint is dropped? > > ... when the last NOT NULL or PRIMARY KEY constraint is dropped. We > have to keep attnotnull set when a PK exists even if there's no specific > NOT NULL constraint. Of course, I forgot that. I hope that is not too hard to implement. > > > 2. If a table has a primary key, and a table is created that inherits > > > from it, then the child has its column(s) marked attnotnull but there > > > is no pg_constraint row for that. This is not okay. But what should > > > happen? > > > > > > 1. a CHECK(col IS NOT NULL) constraint is created for each column > > > 2. a PRIMARY KEY () constraint is created > > > > I think it would be best to create a primary key constraint on the > > partition. > > Sorry, I wasn't specific enough. This applies to legacy inheritance > only; partitioning has its own solution (as you say: the PK constraint > exists), but legacy inheritance works differently. Creating a PK in > children tables is not feasible (because unicity cannot be maintained), > but creating a CHECK (NOT NULL) constraint is possible. > > I think a PRIMARY KEY should not be allowed to exist in an inheritance > parent, precisely because of this problem, but it seems too late to add > that restriction now. This behavior is absurd, but longstanding: My mistake; you clearly said "inherits". Since such an inheritance child currently does not have a primary key, you can insert duplicates. So automatically adding a NUT NULL constraint on the inheritance child seems the only solution that does not break backwards compatibility. pg_upgrade would have to be able to cope with that. Forcing a primary key constraint on the inheritance child could present an upgrade problem. Even if that is probably a rare and strange case, I don't think we should risk that. Moreover, if we force a primary key on the inheritance child, using ALTER TABLE ... INHERIT might have to create a unique index on the table, which can be cumbersome if the table is large. So I think a NOT NULL constraint is the least evil. Yours, Laurenz Albe