Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michel Pelletier <pelletier.michel@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-01-26T10:07:22Z
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.

Hello everyone in this thread.

> On 21 Jan 2025, at 23:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> somebody will review this

I'm trying to dig into the patch set. My knowledge of the module is shallow and I hope to improve it by reading more patches in this area.

This patch set provides a new test, which runs just fine without the patch. But it's somewhat expected, such optimizations must be transparent for user...

And the coverage of newly invented mark_stmt() 42.37%. Some of branches are easy noops, but some are not.
I assume as a granted that we will not every get into infinite loop in a recursive call of mark_stmt().

expr_is_assignment_source() is named like if it should return nool, but it's void.

I could not grasp from reading the code one generic question about new optimization rule. What cost does checking for possible in-place update incurs to code cannot have this optimization? Is it O(numer_of_arguments) of for every assignment execution?

Thanks!


Best regards, Andrey Borodin.