Re: Can't find not null constraint, but \d+ shows that
От | Alvaro Herrera |
---|---|
Тема | Re: Can't find not null constraint, but \d+ shows that |
Дата | |
Msg-id | 202403261525.ciahntfgj25o@alvherre.pgsql обсуждение исходный текст |
Ответ на | Can't find not null constraint, but \d+ shows that (Tender Wang <tndrwang@gmail.com>) |
Ответы |
Re: Can't find not null constraint, but \d+ shows that
Re: Can't find not null constraint, but \d+ shows that Re: Can't find not null constraint, but \d+ shows that Re: Can't find not null constraint, but \d+ shows that |
Список | pgsql-hackers |
On 2024-Mar-26, Tender Wang wrote: > postgres=# CREATE TABLE t1(c0 int, c1 int); > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > postgres=# ALTER TABLE t1 DROP c1; > > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL; > ERROR: could not find not-null constraint on column "c0", relation "t1" Ooh, hah, what happens here is that we drop the PK constraint indirectly, so we only go via doDeletion rather than the tablecmds.c code, so we don't check the attnotnull flags that the PK was protecting. > The attached patch is my workaround solution. Look forward your apply. Yeah, this is not a very good approach -- I think you're just guessing that the column is marked NOT NULL because a PK was dropped in the past -- but really what this catalog state is, is corrupted contents because the PK drop was mishandled. At least in theory there are other ways to drop a constraint other than dropping one of its columns (for example, maybe this could happen if you drop a collation that the PK depends on). The right approach is to ensure that the PK drop always does the dance that ATExecDropConstraint does. A good fix probably just moves some code from dropconstraint_internal to RemoveConstraintById. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ <inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell <crab> inflex: you know that "amalgam" means "mixture with mercury", more or less, right? <crab> i.e., "deadly poison"
В списке pgsql-hackers по дате отправления: