On Fri, May 7, 2021 at 9:16 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > David Rowley <dgrowle...@gmail.com> writes: > > On Sat, 8 May 2021 at 09:15, James Coleman <jtc...@gmail.com> wrote: > >> On Sat, Apr 24, 2021 at 6:25 AM David Rowley <dgrowle...@gmail.com> wrote: > >>> I'm a bit undecided if it's safe to set the opfuncid to the negator > >>> function. If anything were to set that again based on the opno then > >>> it would likely set it to the wrong thing. We can't go changing the > >>> opno either because EXPLAIN would display the wrong thing. > > >> I don't personally see a reason why this is a problem. But I also > >> don't know that I have enough knowledge of the codebase to say that > >> definitively. > > > The reason for my concern is that if the opfuncid is set to > > InvalidOid, set_sa_opfuncid() always sets the ScalarArrayOpExpr's > > opfuncid to get_opcode(opexpr->opno). > > I will personally veto any design that involves setting opfuncid to > something that doesn't match the opno. That's just horrid, and it > will break something somewhere, either immediately or down the road.
This is the "project design" style/policy I don't have. Thanks. > I don't immediately see why you can't add an "invert" boolean flag to > ScalarArrayOpExpr and let the executor machinery deal with this. That'd > have the advantage of not having to depend on there being a negator. Don't we need to have a negator to be able to look up the proper has function? At least somewhere in the process you'd have to convert from looking up the <> op to looking up the = op and then setting the "invert" flag. James
