Re: GSoC 2017: Foreign Key Arrays

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

Best Regards,
Mark Rofail