From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jeremyevans0(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta |
Date: | 2020-08-22 16:37:27 |
Message-ID: | 2206633.1598114247@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> The following SQL worked as expected in previous PostgreSQL versions (at
> least 8.4-12):
> CREATE TABLE "items" ("id" integer NOT NULL, "item_id" integer NOT
> NULL);
> ALTER TABLE "items" ADD UNIQUE ("item_id", "id"), ADD FOREIGN KEY ("id",
> "item_id") REFERENCES "items"("item_id", "id");
> In PostgreSQL 13 beta 3, it results in an error: there is no unique
> constraint matching given keys for referenced table "items"
Yup, that's my fault; fix pushed.
> I'm not sure whether this is considered a bug. It broke a couple tests for
> a database access library I maintain, but I could easily modify them if this
> isn't considered a bug.
Yeah, I think it's a bug, especially since the case used to work.
ALTER TABLE generally believes that it's smarter than you are about
the order in which the subcommands need to be executed; so it has
to hold up its end of the bargain.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-08-22 16:54:46 | Re: BUG #16547: ECPG can't CALL the procedure which has INOUT parameter |
Previous Message | Michael Meskes | 2020-08-22 15:52:23 | Re: BUG #16547: ECPG can't CALL the procedure which has INOUT parameter |