Re: Using Expanded Objects other than Arrays from plpgsql
| От | Michel Pelletier |
|---|---|
| Тема | Re: Using Expanded Objects other than Arrays from plpgsql |
| Дата | |
| Msg-id | CACxu=vK9zZRVasn3Pmn3tbe8z715rPWiXtQ=rKzF9_KbUcH2QA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Using Expanded Objects other than Arrays from plpgsql (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Using Expanded Objects other than Arrays from plpgsql
|
| Список | pgsql-hackers |
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;
$$;
RETURNS bigint LANGUAGE plpgsql AS
$$
BEGIN
perform set_element(graph, 1, 1, 1);
RETURN nvals(graph);
end;
$$;
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@sss.pgh.pa.us> wrote:
Michel Pelletier <pelletier.michel@gmail.com> writes:
> On Wed, Oct 23, 2024 at 8:21 AM Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: