Re: Using Expanded Objects other than Arrays from plpgsql

From: Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Date: 2024-11-02 00:50:52
Message-ID: CACxu=vKxR_1RGrjppLDjnhRj4Sd-QEMeqt+2gPz0myK8kq6q0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Fri, Nov 1, 2024 at 3:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
>
> 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);
>

Ah my bad, you mentioned that already and I missed it, here's the two
backtraces with the assignment:

https://gist.githubusercontent.com/michelp/20b917686149d482be2359569845f232/raw/ca8349ae4b0469674b4b2c77f34c5a02553583a9/gistfile1.txt

>
> regards, tom lane
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michel Pelletier 2024-11-02 00:53:14 Re: Using Expanded Objects other than Arrays from plpgsql
Previous Message Adrian Klaver 2024-11-01 23:53:46 Re: Plans for partitioning of inheriting tables

Browse pgsql-hackers by date

  From Date Subject
Next Message Michel Pelletier 2024-11-02 00:53:14 Re: Using Expanded Objects other than Arrays from plpgsql
Previous Message Noah Misch 2024-11-01 23:38:29 Re: Inval reliability, especially for inplace updates