From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Mark Rofail" <markm(dot)rofail(at)gmail(dot)com> |
Cc: | "Zhihong Yu" <zyu(at)yugabyte(dot)com>, "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, "Alexander Korotkov" <aekorotkov(at)gmail(dot)com>, "Andreas Karlsson" <andreas(at)proxel(dot)se>, "David Steele" <david(at)pgmasters(dot)net>, "Erik Rijkers" <er(at)xs4all(dot)nl>, Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Stephen Frost" <sfrost(at)snowman(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Michael Paquier" <michael(at)paquier(dot)xyz> |
Subject: | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Date: | 2021-02-04 06:59:38 |
Message-ID: | 5cbefa02-4554-4c9b-b96f-6703e3321c75@www.fastmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 2, 2021, at 13:51, Mark Rofail wrote:
>Array-ELEMENT-foreign-key-v17.patch
When working on my pit tool, I found another implicit type casts problem.
First an example to show a desired error message:
CREATE TABLE a (
a_id smallint,
PRIMARY KEY (a_id)
);
CREATE TABLE b (
b_id bigint,
a_ids text[],
PRIMARY KEY (b_id)
);
ALTER TABLE b ADD FOREIGN KEY (EACH ELEMENT OF a_ids) REFERENCES a;
The below error message is good:
ERROR: foreign key constraint "b_a_ids_fkey" cannot be implemented
DETAIL: Key column "a_ids" has element type text which does not have a default btree operator class that's compatible with class "int2_ops".
But if we instead make a_ids a bigint[], we don't get any error:
DROP TABLE b;
CREATE TABLE b (
b_id bigint,
a_ids bigint[],
PRIMARY KEY (b_id)
);
ALTER TABLE b ADD FOREIGN KEY (EACH ELEMENT OF a_ids) REFERENCES a;
No error, even though bigint[] isn't compatible with smallint.
We do get an error when trying to insert into the table:
INSERT INTO a (a_id) VALUES (1);
INSERT INTO b (b_id, a_ids) VALUES (2, ARRAY[1]);
ERROR: operator does not exist: smallint[] pg_catalog.<@ bigint[]
LINE 1: ..."."a" x WHERE ARRAY ["a_id"]::pg_catalog.anyarray OPERATOR(p...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
QUERY: SELECT 1 WHERE (SELECT pg_catalog.count(DISTINCT y) FROM pg_catalog.unnest($1) y) OPERATOR(pg_catalog.=) (SELECT pg_catalog.count(*) FROM (SELECT 1 FROM ONLY "public"."a" x WHERE ARRAY ["a_id"]::pg_catalog.anyarray OPERATOR(pg_catalog.<@) $1::pg_catalog.anyarray FOR KEY SHARE OF x) z)
I wonder if we can come up with some general way to detect these
problems already at constraint creation time,
instead of having to wait for data to get the error,
similar to why compile time error are preferred over run time errors.
/Joel
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-02-04 07:08:43 | Re: Typo in tablesync comment |
Previous Message | Michael Paquier | 2021-02-04 06:54:29 | Re: Removing support for COPY FROM STDIN in protocol version 2 |