Re: [HACKERS] GSoC 2017: Foreign Key Arrays

What is the limitation?

Why is there a limitation?

Why is it a limitation?

What can we do?

Is it feasible? 

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. 

the planner may choose an optimization of this sort when the index's opclass matches the one

DISTINCT will use, ie the default for the data type.

necessary because ri_triggers.c relies on COUNT(DISTINCT x) on the element type, as well as on array_eq() on the array type, and we need those operations to have the same notion of equality that we're using otherwise.

That's wrong: DISTINCT should use the equality operator that corresponds

to the index' operator class instead, not the default one.

I'm sure that we can replace array_eq() with a newer polymorphic version but I don't know how we could get around COUNT(DISTINCT x)