| Lists: | pgsql-hackers |
|---|
| From: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | ALTER TABLE ONLY ...DROP CONSTRAINT is broken in HEAD. |
| Date: | 2011-09-12 15:53:44 |
| Message-ID: | 5BC7F4FA-62EA-437E-B341-A4B01B722BAD@commandprompt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
This works in 9.1, but not in HEAD:
CREATE TABLE parent(id INTEGER, CONSTRAINT id_check CHECK(id>1));
CREATE TABLE child() INHERITS(parent);
ALTER TABLE ONLY parent DROP CONSTRAINT id_check;
I'm getting:
ERROR: relation 16456 has non-inherited constraint "id_check"
where 16456 is the oid of the child table.
It seems that the pg_constraint scan at ATExecDropConstraint (tablecmds.c:6751) is re-reading those tuples that were updated in the previous iterations of this scan, at least that's what I've observed in gdb. I'm not sure how to fix this yet.
--
Alexey Klyukin http://www.commandprompt.com
The PostgreSQL Company – Command Prompt, Inc.
| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Alexey Klyukin <alexk(at)commandprompt(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ALTER TABLE ONLY ...DROP CONSTRAINT is broken in HEAD. |
| Date: | 2011-10-24 16:20:29 |
| Message-ID: | CA+TgmoYvjvT=JZowP2bA4G5bCm37Y7rvXPWc85rkpGkG+5aDHg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-hackers |
On Mon, Sep 12, 2011 at 11:53 AM, Alexey Klyukin
<alexk(at)commandprompt(dot)com> wrote:
> This works in 9.1, but not in HEAD:
>
> CREATE TABLE parent(id INTEGER, CONSTRAINT id_check CHECK(id>1));
> CREATE TABLE child() INHERITS(parent);
>
> ALTER TABLE ONLY parent DROP CONSTRAINT id_check;
>
> I'm getting:
> ERROR: relation 16456 has non-inherited constraint "id_check"
> where 16456 is the oid of the child table.
>
> It seems that the pg_constraint scan at ATExecDropConstraint (tablecmds.c:6751) is re-reading those tuples that were updated in the previous iterations of this scan, at least that's what I've observed in gdb. I'm not sure how to fix this yet.
Woops, seems this got overlooked. It's been fixed, though: see commit
c0f03aae0469e758964faac0fb741685170c39a5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company