Re: Using Expanded Objects other than Arrays from plpgsql

Andrey Borodin <x4mmm@yandex-team.ru>

From: Andrey Borodin <x4mmm@yandex-team.ru>

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

Cc: Pavel Borisov <pashkin.elfe@gmail.com>, Michel Pelletier <pelletier.michel@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-02-03T19:15:02Z

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 3 Feb 2025, at 23:18, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> But I don't want to think of
> EEOP_PARAM_CALLBACK as being specifically tied to PL/pgSQL.

I've found 1 users on Github [0]. And a lot of copied code like [1]. And there might be some unindexed cases.
Let's keep paramarg2.

Best regards, Andrey Borodin.
[0] https://github.com/wanglinn/xadb/blob/7695b7edcb0a89f3173b648c0da5b953538f2aa9/src/backend/pgxc/pool/execRemote.c#L835
[1] https://github.com/babelfish-for-postgresql/babelfish_extensions/blob/376cf488804fa02f9b1db5bbfbe74e98627fe96c/contrib/babelfishpg_tsql/src/pl_exec.c#L8030