From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
cc: redraiment@gmail.com, pgsql-bugs@lists.postgresql.org,
        Andres Freund <andres@anarazel.de>
Subject: Re: BUG #19370: PG18 returns incorrect array slice results when slice
 bounds depend on another array expression
In-reply-to: 
 <CAApHDvpVwUTNEQKkBVD9CQCq6N+YW7hpH6C3ZtKJQnGX4XAtpA@mail.gmail.com>
References: <19370-7fb7a5854b7618f1@postgresql.org>
 <CAApHDvpVwUTNEQKkBVD9CQCq6N+YW7hpH6C3ZtKJQnGX4XAtpA@mail.gmail.com>
Comments: In-reply-to David Rowley <dgrowleyml@gmail.com>
	message dated "Tue, 06 Jan 2026 22:26:19 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1588383.1767715181.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 06 Jan 2026 10:59:41 -0500
Message-ID: <1588384.1767715181@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1588384.1767715181%40sss.pgh.pa.us>
Precedence: bulk

David Rowley <dgrowleyml@gmail.com> writes:
> On Tue, 6 Jan 2026 at 21:22, PG Bug reporting form
> <noreply@postgresql.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 expre=
ssion
>> 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