From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18722: Processing arrays with plpgsql raises errors
In-reply-to: 
 <CAEZATCWKt=XKP12qZhqBX4JaVSatmFwYFnoGYEDDqCbpe-HrEA@mail.gmail.com>
References: <18722-fd9e645448cc78b4@postgresql.org>
 <940942.1732412520@sss.pgh.pa.us> <1211277.1732488552@sss.pgh.pa.us>
 <CAEZATCWKt=XKP12qZhqBX4JaVSatmFwYFnoGYEDDqCbpe-HrEA@mail.gmail.com>
Comments: In-reply-to Dean Rasheed <dean.a.rasheed@gmail.com>
	message dated "Mon, 25 Nov 2024 10:30:23 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1341818.1732547251.1@sss.pgh.pa.us>
Date: Mon, 25 Nov 2024 10:07:31 -0500
Message-ID: <1341819.1732547251@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1341819.1732547251%40sss.pgh.pa.us>
Precedence: bulk

Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> On Sun, 24 Nov 2024 at 22:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Here's a fleshed-out patch with a test case and JIT support.  This
>> is about the first time I've messed with LLVM, so I wouldn't mind
>> some review of what I did in llvmjit_expr.c.  In particular, do I
>> correctly understand that "l_funcvalue(b, v_fcinfo, 0)" produces
>> a reference to a copy of the initial value of args[0].value?

> I don't know about that, but I wonder if this bug could be fixed by
> having ExecInitExprRec() insert a EEOP_MAKE_READONLY step. Then it
> wouldn't be necessary to make any changes to the expression evaluation
> code.

That would entirely destroy one of the primary performance benefits of
the expanded-object infrastructure.  The idea is that if you have
    fconsumer(fproducer(...), ...)
and fproducer returns a read-write pointer to an object it's built,
then fconsumer should be able to take ownership of the object and
use it as a local variable (possibly modifying it) without incurring
any object-copying overhead.

This works in any context where an intermediate expression value
has a single consumer, which is most.  If there are multiple
consumers then we need to insert MAKE_READONLY steps for all
(or all but one) of them.  I overlooked EEOP_NULLIF as such
a case, but I don't think there are so many more cases as to
justify throwing away the concept altogether.

			regards, tom lane