Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Pavel Borisov <pashkin.elfe@gmail.com>

View thread
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Michel Pelletier <pelletier.michel@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-01-30T20:32:03Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow extension functions to participate in in-place updates.

  2. Implement new optimization rule for updates of expanded variables.

  3. Detect whether plpgsql assignment targets are "local" variables.

  4. Preliminary refactoring of plpgsql expression construction.

  5. Refactor pl_funcs.c to provide a usage-independent tree walker.

  6. Generalize plpgsql's heuristic for importing expanded objects.

Hi, Michel and Tom!

On Sun, 26 Jan 2025 at 23:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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 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