Thread: BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta

The following bug has been logged on the website:

Bug reference:      16589
Logged by:          Jeremy Evans
Email address:      jeremyevans0@gmail.com
PostgreSQL version: 13beta3
Operating system:   OpenBSD-current
Description:

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"

This is trivial to work around by splitting the ALTER TABLE commands:

  CREATE TABLE "items" ("id" integer NOT NULL, "item_id" integer NOT
NULL);
  ALTER TABLE "items" ADD UNIQUE ("item_id", "id");
  ALTER TABLE "items" ADD FOREIGN KEY ("id", "item_id") REFERENCES
"items"("item_id", "id");

My guess would be that the ADD FOREIGN KEY preconditions are now checked
before the ADD UNIQUE change is executed, but that isn't an educated
guess.

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.

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