Re: Using Expanded Objects other than Arrays from plpgsql

Michel Pelletier <pelletier.michel@gmail.com> writes:
> On Wed, Dec 18, 2024 at 12:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So, just to clarify where we're at: you are satisfied that the current
>> patch-set does what you need?

> There are a few cases where I have to force an expansion, I work around
> this by calling a `wait()` function, which expands the datum, calls
> GrB_wait() on it (a nop in this case) and returns a r/w pointer.  You can
> see this in the following Triangle Counting function which is a matrix
> multiplication of a graph to itself, using itself as a mask.  This matrix
> reduces to the triangle count (times six):

> create or replace function tcount_b(graph matrix) returns bigint language
> plpgsql as
>     $$
>     begin
>         graph = wait(graph);
>         graph = mxm(graph, graph, 'plus_pair_int32', mask=>graph,
> descr=>'s');
>         return reduce_scalar(graph) / 6;
>     end;
>     $$;

> ...
> I agree it makes sense to have more use cases before making deeper
> changes.  I only work with expanded forms,  but need to call wait() to
> pre-expand the object to avoid multiple expansions in functions that can
> take the same object in multiple parameters.

Hmm.  I agree that the wait() call is a bit ugly, but there are at
least two things that seem worth looking into before we go so far
as inventing type-support infrastructure:

1. Why isn't the incoming "graph" object already expanded?  It
often would be read-only, but that seems like it might be enough
given your description of GraphBLAS' behavior.

2. If the problem is primarily with passing the same object to
multiple parameters of a function, couldn't you detect and optimize
that within the function?  It would be messier than just blindly
applying DatumGetWhatever() to each parameter position; but with a
bit of thought I bet you could create some support logic that would
hide most of the mess.

			regards, tom lane