On Thu, Apr 11, 2024 at 3:19 PM Tender Wang <tndrw...@gmail.com> wrote: > >> +DROP TABLE notnull_tbl1; >> +-- make sure attnotnull is reset correctly when a PK is dropped indirectly >> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1)); >> +ALTER TABLE notnull_tbl1 DROP c1; >> +\d+ notnull_tbl1 >> + Table "public.notnull_tbl1" >> + Column | Type | Collation | Nullable | Default | Storage | Stats >> target | Description >> +--------+---------+-----------+----------+---------+---------+--------------+------------- >> + c0 | integer | | not null | | plain | >> | >> + >> >> this is not what we expected? >> "not null" for "c0" now should be false? >> am I missing something? > > Yeah, now this is expected behavior. > Users can drop manually not-null of "c0" if they want, and no error reporte. >
sorry for the noise. these two past patches confused me: 0001-Correctly-reset-attnotnull-when-constraints-dropped-.patch v4-0001-Fix-pg_attribute-attnotnull-not-reset-when-droppe.patch I thought dropping a column of primary key (ALTER TABLE notnull_tbl2 DROP c1) will make the others key columns to not have "not null" property. now I figured out that dropping a column of primary key columns will not change other key columns' "not null" property. dropping the primary key associated constraint will make all key columns "not null" property disappear. v2-0001-Handle-ALTER-.-DROP-NOT-NULL-when-no-pg_constrain.patch behavior looks fine to me now. inline drop_orphaned_notnull in ATExecDropNotNull looks fine to me.
