Re: Can't find not null constraint, but \d+ shows that
Tender Wang <tndrwang@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: jian he <jian.universality@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-28T12:05:04Z
Lists: pgsql-hackers
Attachments
- v4-0001-Fix-pg_attribute-attnotnull-not-reset-when-droppe.patch (application/octet-stream) patch v4-0001
Alvaro Herrera <alvherre@alvh.no-ip.org> 于2024年3月28日周四 17:18写道: > On 2024-Mar-28, Tender Wang wrote: > > > RemoveConstraintById() should think recurse(e.g. partition table)? I'm > not > > sure now. > > If we should think process recurse in RemoveConstraintById(), the > > function will look complicated than before. > > No -- this function handles just a single constraint, as identified by > OID. The recursion is handled by upper layers, which can be either > dependency.c or tablecmds.c. I think the problem you found is caused by > the fact that I worked with the tablecmds.c recursion and neglected the > one in dependency.c. > Indeed. create table skip_wal_skip_rewrite_index (c varchar(10) primary key); alter table skip_wal_skip_rewrite_index alter c type varchar(20); Above SQL need attnotnull to be true when re-add index, but RemoveConstraintById() is hard to recognize this scenario as I know. We should re-set attnotnull to be true before re-add index. I add a new AT_PASS in attached patch. Any thoughts? -- Tender Wang OpenPie: https://en.openpie.com/
Commits
-
Better handle indirect constraint drops
- 0cd711271d42 17.0 landed
-
Add macros for looping through a List without a ListCell.
- 14dd0f27d7cd 17.0 cited