Mark Rofail wrote: > On Tue, Jul 18, 2017 at 11:14 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: > > > > Why did we add an operator and not a support > > procedure? > > I thought the support procedures were constant within an opclass.
Uhh ... I apologize but I think I was barking at the wrong tree. I was thinking that it mattered that the opclass mechanism was able to determine whether some array @>> some element, but that's not true: it's the queries in ri_triggers.c, which have no idea about opclasses. (I tihnk we would have wanted to use to opclasses in order to find out what operator to use in the first place, if ri_triggers.c was already using that general idea; but in reality it's already using hardcoded operator names, so it doesn't matter.) I'm not entirely sure what's the best way to deal with the polymorphic problem, but on the other hand as Robert says downthread maybe we shouldn't be solving it at this stage anyway. So let's step back a bit, get a patch that works for the case where the types match on both sides of the FK, then we review that patch; if all is well, we can discuss the other problem as a stretch goal. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers