Re: [HACKERS] GSoC 2017: Foreign Key Arrays

These are limitations of the patch ordered by importance:

✗ presupposes that count(distinct y) has exactly the same notion of equality that the PK unique index has. In reality, count(distinct) will fall back to the default btree opclass for the array element type. 

- Supported actions:

 ✔ NO ACTION

 ✔ RESTRICT

 ✗ CASCADE

 ✗ SET NULL

 ✗ SET DEFAULT 

✗ coercion is unsopported. i.e. a numeric can't refrence int8

✗ Only one "ELEMENT" column allowed in a multi-column key

✗ undesirable dependency on default opclass semantics in the patch, which is that it supposes it can use array_eq() to detect whether or not the referencing column has changed.  But I think that can be fixed without undue pain by providing a refactored version of array_eq() that can be told which element-comparison function to use

✗ cross-type FKs are unsupported

-- Resolved limitations =============================

✔ fatal performance issues.  If you issue any UPDATE or DELETE against the PK table, you get a query like this for checking to see if the RI constraint would be violated: 

SELECT 1 FROM ONLY fktable x WHERE $1 = ANY (fkcol) FOR SHARE OF x;

/* Changed into SELECT 1 FROM ONLY fktable x WHERE $1 @> fkcol FOR SHARE OF x; */

-- ============================================

Can someone help me understand the first limitation?