Andrey Borodin <x4...@yandex-team.ru> writes:
> On 26 Jan 2025, at 20:37, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Maybe we should recast it as an action. What do you think of
>> "mark_expr_as_assignment_source"?
> Sounds better to me. I found no examples of similar functions nether in
> pl_gram.y, nor in gram.y, so IMO mark_expr_as_assignment_source() is the best
> candidate.
WFM, I'll make it so in next version.
> Got it, many thanks for the explanation.
I'll see about incorporating more of that in the comments, too.
> I wonder if you plan similar optimizations for array_cat(), array_remove()
> etc?
> + a := a || a; -- not optimizable
> Why is it not optimizable? Because there is no support function, because
> array_cat() has no support function, or something else?
plpgsql won't attempt to optimize it because "a" is referenced twice
and there is no support function that might say it's safe anyway.
array_cat doesn't currently have any special smarts about expanded
arrays, so it's all moot because the arrays would get flattened
on the way into it. If we did improve it to be able to cope with
expanded arrays, I'm not real sure that it could safely manage an
in-place update where the two inputs are the same array --- at
the least, some extreme care would be needed to get the right
answers.
I'm not real excited about optimizing additional array operations
anyway. Maybe some more will get done at some point, but I don't
see that as part of this work.
regards, tom lane
