On 2018-Jun-07, David Rowley wrote: > On 7 June 2018 at 15:57, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Hm I was thinking this new function would be companion to ExecConstrains > > (a fact I used in the name I proposed,) so it'd be in the same file > > (probably right after it.) > > Okay. v5 (attached) does it that way.
Thanks, looks nice (function name is stupidly long, my fault). I wondered about the refactoring that Amit Khandekar is proposing. Given the improved API you gave the new function, it appears we can write it like this (untested): bool ExecConstraintsPartConstrNeedsRecheck(ResultRelInfo *resultRelInfo, bool tupleRouting) { if (tupleRouting) { if (resultRelInfo->ri_TrigDesc && resultRelInfo->ri_TrigDesc->trig_insert_before_row) return true; } else if (resultRelInfo->ri_PartitionCheck != NIL) return true; return false; /* no need to recheck */ } I was also wondering about introducing a new function call in this path where previously was none. Given the amount of other stuff that's happening when a tuple is inserted, I suppose it's not worth worrying about in terms of making this an inline function in the header. BTW I noticed that ExecConstraints() indicates that the given resultRelInfo is "the original resultRelInfo, before tuple routing", but that's demostrably false. What's up with that? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services