Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Tue, 6 Jan 2026 at 21:22, PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> I have encountered a behavioral regression in PostgreSQL 18 related to array
>> slicing when the slice start index is computed from another array expression
>> in the same SELECT list.

> Many thanks for the report and reproducer. I've not looked as to why,
> but this seems to be caused by a7f107df2. I've included Andres.

After re-reading that patch, I suspect an aliasing problem,
specifically from this bit in ExecInitSubPlanExpr:

* ... No
* danger of conflicts with other uses of resvalue/resnull as storing and
* using the value always is in subsequent steps.

ExecInitExprRec(arg, state,
&state->resvalue, &state->resnull);

The comment seems perhaps too airy :-(. I experimented with replacing

- &state->resvalue, &state->resnull);
+ resv, resnull);

and indeed that makes the submitted query work --- but it breaks other
queries in our regression tests, so it's not a usable solution.

I don't see a good reason why ExecInitSubPlanExpr shouldn't be allowed
to use state->resvalue/resnull this way. Given that the problem seems
specific to array slicing, I'm suspicious that some step in array
slicing is failing to cope with input and output datum storage being
the same, or something close to that.

regards, tom lane