Hey Tom,
I managed to get a test that fails without my patch, and added it to
the intarray tests. Without the patch, the query returns 0 records.
With my patch, the results are correct (12 records).
Please find attached the updated patch with a fix & a test in the
intarray contrib. Thanks for the pointer to the contrib extensions.
-Vinod
On Fri, 11 Apr 2025 at 22:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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
