public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Michel Pelletier <[email protected]>
Cc: [email protected]
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Date: Wed, 23 Oct 2024 11:21:25 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACxu=v+t5xDh0K=tOVmFrumvAH60izWhB16a9k7f2A8jPxQEaw@mail.gmail.com>
References: <CACxu=vJaKFNsYxooSnW1wEgsAO5u_v1XYBacfVJ14wgJV_PYeg@mail.gmail.com>
<[email protected]>
<CACxu=vLXvpzN4X3k+9jsMt6ujuOvFVUSkA80t_cROSsF4y2jQQ@mail.gmail.com>
<[email protected]>
<CACxu=vKEF8Qa-OaADFxf0uMg-xw6gH_CNCWd2s+xaqh-gY4=xg@mail.gmail.com>
<[email protected]>
<CACxu=v+t5xDh0K=tOVmFrumvAH60izWhB16a9k7f2A8jPxQEaw@mail.gmail.com>
Michel Pelletier <[email protected]> writes:
> Here's another example:
> CREATE OR REPLACE FUNCTION test2(graph matrix)
> RETURNS bigint LANGUAGE plpgsql AS
> $$
> BEGIN
> perform set_element(graph, 1, 1, 1);
> RETURN nvals(graph);
> end;
> $$;
> CREATE FUNCTION
> postgres=# select test2(matrix('int32'));
> DEBUG: new_matrix
> DEBUG: matrix_get_flat_size
> DEBUG: flatten_matrix
> DEBUG: scalar_int32
> DEBUG: new_scalar
> DEBUG: matrix_set_element
> DEBUG: DatumGetMatrix
> DEBUG: expand_matrix
> DEBUG: new_matrix
> DEBUG: DatumGetScalar
> DEBUG: matrix_get_flat_size
> DEBUG: matrix_get_flat_size
> DEBUG: flatten_matrix
> DEBUG: context_callback_matrix_free
> DEBUG: context_callback_scalar_free
> DEBUG: matrix_nvals
> DEBUG: DatumGetMatrix
> DEBUG: expand_matrix
> DEBUG: new_matrix
> DEBUG: context_callback_matrix_free
> DEBUG: context_callback_matrix_free
> test2
> -------
> 0
> (1 row)
I'm a little confused by your debug output. What are "scalar_int32"
and "new_scalar", and what part of the plpgsql function is causing
them to be invoked?
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?
> I would expect that to return 1. If I do "graph = set_element(graph, 1, 1,
> 1)" it works.
I think you have a faulty understanding of PERFORM. It's defined as
"evaluate this expression and throw away the result", so it's *not*
going to change "graph", not even if set_element declares that
argument as INOUT. (Our interpretation of OUT arguments for functions
is that they're just an alternate notation for specifying the function
result.) If you want to avoid the explicit assignment back to "graph"
then the thing to do would be to declare set_element as a procedure,
not a function, with an INOUT argument and then call it with CALL.
That's only cosmetically different though, in that the updated
"graph" value is still passed back much as if it were a function
result, and then the CALL infrastructure knows it has to assign that
back to the argument variable. And, as I tried to explain earlier,
that code path currently has no mechanism for avoiding making a copy
of the graph somewhere along the line: it will pass "graph" to the
procedure as either a flat Datum or a R/O expanded object, so that
set_element will be required to copy that before modifying it.
We can imagine extending whatever we do for "x := f(x)" cases so that
it also works during "CALL p(x)". But I think that's only going to
yield cosmetic or notational improvements so I don't want to start
with doing that. Let's focus first on improving the existing
infrastructure for the f(x) case.
regards, tom lane
view thread (6+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox