BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta - Mailing list pgsql-bugs

From PG Bug reporting form
Subject BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta
Date
Msg-id 16589-31c8d981ca503896@postgresql.org
Whole thread Raw
Responses Re: BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta
List pgsql-bugs
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.


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS
Next
From: Peter Geoghegan
Date:
Subject: Re: BUG #16586: deduplicate_items=true can be configured for numeric indexes