Hi Alvaro, I met an issue related to Catalog not-null commit on HEAD.
postgres=# CREATE TABLE t1(c0 int, c1 int);
CREATE TABLE
postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1);
ALTER TABLE
postgres=# \d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Storage | Compression
| Stats target | Description
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
c0 | integer | | not null | | plain |
| |
c1 | integer | | not null | | plain |
| |
Indexes:
"q" PRIMARY KEY, btree (c0, c1)
Access method: heap
postgres=# ALTER TABLE t1 DROP c1;
ALTER TABLE
postgres=# \d+ t1
Table "public.t1"
Column | Type | Collation | Nullable | Default | Storage | Compression
| Stats target | Description
--------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
c0 | integer | | not null | | plain |
| |
Access method: heap
postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL;
ERROR: could not find not-null constraint on column "c0", relation "t1"
postgres=# insert into t1 values (NULL);
ERROR: null value in column "c0" of relation "t1" violates not-null
constraint
DETAIL: Failing row contains (null).
I couldn't reproduce aboved issue on older version(12.12 ...16.1).
to be more precisely， since b0e96f3119 commit.
Without the b0e96f3119, when we drop not null constraint, we just update
the pg_attribute attnotnull to false
in ATExecDropNotNull(). But now we first check pg_constraint if has the
tuple. if attnotnull is ture, but pg_constraint
doesn't has that tuple. Aboved error will report.
It will be confuesed for users. Because \d shows the column c0 has not
null, and we cann't insert NULL value. But it
reports errore when users drop the NOT NULL constraint.
The attached patch is my workaround solution. Look forward your apply.
--
Tender Wang
OpenPie: https://en.openpie.com/
0001-Fix-attnotnull-not-correct-reset-issue.patch
Description: Binary data
