What is the limitation?
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.
Why is there a limitation?
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.
Why is it a limitation?
That's wrong: DISTINCT should use the equality operator that corresponds
to the index' operator class instead, not the default one.
What can we do ?
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)
Is it feasible?