Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier <pelletier.michel@gmail.com>

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

On Sun, Feb 2, 2025 at 1:57 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I wrote:
> > Hmm, it seemed to still apply for me.  But anyway, I needed to make
> > the other changes, so here's v4.
>
> PFA v5.  The new 0001 patch refactors the free_xxx infrastructure
> to create plpgsql_statement_tree_walker(), and then in what's now
> 0003 we can use that instead of writing a lot of duplicate code.
>

Thanks Tom!  These patches apply for me and all my tests and benchmarks are
still good.

-Michel