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

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: jeremyevans0(at)gmail(dot)com
Subject: BUG #16589: Regression when using ADD UNIQUE+ADD FOREIGN KEY in same query in 13 beta
Date: 2020-08-21 20:54:58
Message-ID: 16589-31c8d981ca503896@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 16589
Logged by: Jeremy Evans
Email address: jeremyevans0(at)gmail(dot)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.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2020-08-21 22:49:03 Re: BUG #16586: deduplicate_items=true can be configured for numeric indexes
Previous Message Tom Lane 2020-08-21 20:49:07 Re: BUG #16585: Wrong filtering on a COALESCE field after using GROUPING SETS