Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier <pelletier.michel@gmail.com>

From: Michel Pelletier <pelletier.michel@gmail.com>

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

Cc: Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-01-21T18:05:48Z

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 →

Allow extension functions to participate in in-place updates.
- c366d2bdba7c 18.0 landed
Implement new optimization rule for updates of expanded variables.
- 6c7251db0ce1 18.0 landed
Detect whether plpgsql assignment targets are "local" variables.
- 36fb9ef269a0 18.0 landed
Preliminary refactoring of plpgsql expression construction.
- a654af21ae52 18.0 landed
Refactor pl_funcs.c to provide a usage-independent tree walker.
- 6a7283dd2f1c 18.0 landed
Generalize plpgsql's heuristic for importing expanded objects.
- 534d0ea6c2b9 18.0 landed

On Wed, Jan 15, 2025 at 10:09 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I noticed that v2 of this patch series failed to apply after
> 7b27f5fd3, so here's v3.  No non-trivial changes.
>

Thanks Tom!  These applied cleanly to my test env and actually increased my
livejournal graph benchmark by a million edges per second, so I guess I
didn't have all the previous changes in my last build as you noted.

-Michel