Re: Using Expanded Objects other than Arrays from plpgsql

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

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

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

Cc: pgsql-hackers@lists.postgresql.org

Date: 2024-11-01T22:20:09Z

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

Michel Pelletier <pelletier.michel@gmail.com> writes:
> Here's two backtraces from gdb from this function:
> CREATE OR REPLACE FUNCTION test2(graph matrix)
>     RETURNS bigint LANGUAGE plpgsql AS
>     $$
>     BEGIN
>     perform set_element(graph, 1, 1, 1);
>     RETURN nvals(graph);
>     end;
>     $$;

Well, you shouldn't be using PERFORM.  Not only does it not do the
right thing, but it's not optimized for expanded objects at all:
they'll get flattened both on the way into the statement and on
the way out.  Try it with

     graph := set_element(graph, 1, 1, 1);
     RETURN nvals(graph);

			regards, tom lane