Re: GSoC 2017: Foreign Key Arrays

On Sun, Jul 9, 2017 at 7:42 PM, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
wrote:

> We may document that GIN index is required to accelerate RI queries for
> array FKs. And users are encouraged to manually define them.
> It's also possible to define new option when index on referencing
> column(s) would be created automatically. But I think this option should
> work the same way for regular FKs and array FKs.
>

I just thought because GIN index is suited for composite elements, it would
be appropriate for array FKs.

So we should leave it to the user ? I think tht would be fine too.

*What I did *

- now the RI checks utilise the @>(anyarray, anyelement)
- however there's a small problem:
operator does not exist: integer[] @> smallint
I assume that external casting would be required here. But how can I
downcast smallint to integer or interger to numeric automatically ?

*What I plan to do*

- work on the above mentioned buy/limitation
- otherwise, I think this concludes limitation #5

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

or is there anything remaining ?

Best Regards,
Mark Rofail