Hey Tom,
I concur with your statement - from a correctness standpoint this
should be what we do.
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.
If we're okay with that, I would prefer to have this contract clean
too - which would also make it better if the consistent path were to
change in the future.
And yeah in that case, I believe my patch is sufficient.
-Vinod
On Fri, 11 Apr 2025 at 20:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Vinod Sridharan <vsridh90@gmail.com> writes:
> > -- create textops operator class without triconsistent
>
> OK, got it, and I concur that we need to make shimTriConsistentFn()
> restore the state of the entryRes array before it returns. But
> I don't understand why you're concerned about "However, this would
> also reset it during the regular triConsistent check per tuple"?
> I think the point is basically that this function is violating
> the expectation that triconsistent functions not change the state
> of that array. That expectation doesn't depend on what the call
> site is.
>
> regards, tom lane
