Andrey Borodin <x4mmm@yandex-team.ru> writes:
> On 26 Jan 2025, at 20:37, Tom Lane <tgl@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
somethingelse?
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
