PG Bug reporting form <noreply@postgresql.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
