Horton

Re: Using Expanded Objects other than Arrays from plpgsql

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Borisov <pashkin.elfe@gmail.com>
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-02-02T21:56:59Z
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.

Attachments

I wrote:
> Hmm, it seemed to still apply for me.  But anyway, I needed to make
> the other changes, so here's v4.

I decided to see what would happen if we tried to avoid the code
duplication in pl_funcs.c by making some "walker" infrastructure
akin to expression_tree_walker.  While that doesn't seem useful
for the dump_xxx functions, it works very nicely for the free_xxx
functions and now for the mark_xxx ones as well.  pl_funcs.c
nets out about 400 lines shorter than in the v4 patch.  The
code coverage score for the file is still awful :-(, but that's
because we're not testing the dump_xxx functions at all.

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.

			regards, tom lane