Vinod Sridharan <vsridh90@gmail.com> writes:
> Since this is also called in the regular consistent function, this
> would be adding work in the regular consistent path - where the caller
> happens to reset the array for every invocation currently.
Ah, so you're just worried about the extra work in that path?
But MAX_MAYBE_ENTRIES is only 4, so I can't believe it'd amount
to much.
I am wondering about a test case. I'm not thrilled about building
a specialized opclass just to test this. contrib/hstore and
contrib/intarray already have opclasses with no triconsistent
function, so they should (and do) exercise shimTriConsistentFn
already. But their tests failed to expose this bug. I spent
a bit of time trying to add an example that would show the bug
in one or the other of those, and failed so far. Any ideas?
regards, tom lane
