Re: Using Expanded Objects other than Arrays from plpgsql

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;
$$;

https://gist.githubusercontent.com/michelp/d02e3e300710443454357222077f9ded/raw/86d9c2c3de3f9b4740065a7b8c29a3e1c54b1cac/gistfile1.txt

Both traces are in that file split on the hyphens line 44. I'm still
puzzling it out, could it have something to do with the volatility of the
functions? I'm not entirely clear on how to interpret function volatility
with expanded objects, nvals is STRICT, but set_element is STABLE. I think
my logic there was because it's a mutation. This is likely another
misunderstanding of mine.

-Michel

On Wed, Oct 23, 2024 at 7:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michel Pelletier <pelletier(dot)michel(at)gmail(dot)com> writes:
> > On Wed, Oct 23, 2024 at 8:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Another thing that confuses me is why there's a second flatten_matrix
> >> operation happening here. Shouldn't set_element return its result
> >> as a R/W expanded object?
>
> > That confuses me too, and my default assumption is always that I'm doing
> it
> > wrong. set_element does return a R/W object afaict, here is the return:
> > https://github.com/OneSparse/OneSparse/blob/main/src/matrix.c#L1726
>
> Hmph. That seems right. Can you add errbacktrace() to your logging
> ereports, in hopes of seeing how we're getting to flatten_matrix?
> Or break there with gdb for a more complete/reliable stack trace.
>
> regards, tom lane
>