| 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 |
| 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 |