On Thu, Apr 11, 2024 at 3:19 PM Tender Wang <tndrwang@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.
