I am sorry for the late reply
== Limitations of the current design
All the limitations are as you said, I don't think we can do much better at the moment
== Functional review
>1) MATCH FULL does not seem to care about NULLS in arrays. In the example below I expected both inserts into the referring table to fail.
It seems in your example the only failed case was: INSERT INTO fk VALUES (NULL, '{1}');
which shouldn't work, can you clarify this?
>2) To me it was not obvious that ON DELETE CASCADE would delete the whole rows rather than delete the members from the array, and this kind of misunderstanding can lead to pretty bad surprises in production. I am leaning towards not supporting CASCADE.
I would say so too, maybe we should remove ON DELETE CASCADE until we have supported all remaining actions.
== The @>> operator
I would argue that allocating an array of datums and building an array would have the same complexity
== Code review
>I think the code in RI_Initial_Check() would be cleaner if you used "CROSS JOIN LATERAL unnest(col)" rather than having unnest() in the target list. This way you would not need to rename all columns and the code paths for the array case could look more like the code path for the normal case.
Can you clarify what you mean a bit more?
== Minor things in the code
All minor things were corrected
== Documentation
All documentation was corrected