Hi, Michel and Tom! On Sun, 26 Jan 2025 at 23:04, Tom Lane <t...@sss.pgh.pa.us> wrote: > > 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
I started looking at the patchset. Recently it got conflicts with changes to yyparse (473a575e05979b4db). Could you rebase it and also do naming changes proposed by Andrew Borodin, which I definitely agree with? Regards, Pavel Borisov
