Fast-path FK checks reject valid inserts for domain-typed FK columns

From: Ewan Young <kdbase(dot)hack(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: amitlangote09(at)gmail(dot)com, Junwang Zhao <zhjwpku(at)gmail(dot)com>
Subject: Fast-path FK checks reject valid inserts for domain-typed FK columns
Date: 2026-06-12 03:36:03
Message-ID: CAON2xHNDFC4cX2atvTpMuC=cK9y7q4J+n3+15w4148AohXEc1w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Commit 2da86c1 ("Add fast path for foreign key constraint checks") makes
a foreign-key column whose type is a domain over a type different from
the referenced PK reject every valid row:

CREATE DOMAIN int8dom AS int8;
CREATE TABLE pk (a int4 PRIMARY KEY);
CREATE TABLE fk (b int8dom REFERENCES pk(a));
INSERT INTO fk VALUES (1);
ERROR: no conversion function from int8dom to integer

It's new in v19 (verified by building 2da86c1^, where the insert
succeeds); no released version is affected. The SPI path still handles
it fine, e.g. with a partitioned PK.

The fast path is the first caller to pass the cross-type pf_eq_oprs
operator to ri_HashCompareOp(). Its "no cast needed" test,

if (typeid == righttype)

fails when the FK column is a domain over righttype (typeid is the
domain OID), so it wrongly concludes no conversion exists and errors out.
Looking through the domain fixes it -- conpfeqop is chosen against the
FK base type, so getBaseType(typeid) == righttype holds for any valid FK:

- if (typeid == righttype)
+ if (getBaseType(typeid) == righttype)

Patch attached, with a regression test in foreign_key.sql. make check
and the isolation suite pass.

Regards,
Ewan Young

Attachment Content-Type Size
v1-0001-Fix-foreign-key-fast-path-for-domain-typed-FK-column.patch application/octet-stream 5.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2026-06-12 03:40:50 Re: Row pattern recognition
Previous Message David Rowley 2026-06-12 03:19:07 Re: Remove redundant DISTINCT when GROUP BY already guarantees uniqueness