Re: BUG #18722: Processing arrays with plpgsql raises errors

On Mon, 25 Nov 2024 at 15:07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> > 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.
>

I didn't mean do it in all cases, I just meant the NullIfExpr case
identified here. My point was that instead of modifying the evaluation
code for EEOP_NULLIF to make it call
MakeExpandedObjectReadOnlyInternal(), it would be easier to insert a
EEOP_MAKE_READONLY step for the first argument of the EEOP_NULLIF
step.

Regards,
Dean