Re: Using Expanded Objects other than Arrays from plpgsql - Mailing list pgsql-general

From Tom Lane
Subject Re: Using Expanded Objects other than Arrays from plpgsql
Date
Msg-id 1445998.1729482404@sss.pgh.pa.us
Whole thread Raw
In response to Re: Using Expanded Objects other than Arrays from plpgsql  (Michel Pelletier <pelletier.michel@gmail.com>)
List pgsql-general
Michel Pelletier <pelletier.michel@gmail.com> writes:
> On Sun, Oct 20, 2024 at 10:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> But it seems like we could get an easy win by adjusting
>> plpgsql_exec_function along the lines of
>> ...

> I tried this change and couldn't get it to work, on the next line:
>     if (VARATT_IS_EXTERNAL_EXPANDED_RW(DatumGetPointer(var->value)))
> var->value might not be a pointer, as it seems at least from my gdb
> scratching, but say an integer.  This segfaults on non-array but
> non-expandable datum.

Oh, duh --- the typisarray test serves to eliminate pass-by-value
types.  We need the same test that exec_assign_value makes,
!var->datatype->typbyval, before it's safe to apply DatumGetPointer.
So line 549 needs to be more like

-                    if (!var->isnull && var->datatype->typisarray)
+                    if (!var->isnull && !var->datatype->typbyval)

> Another comment that caught my eye was this one:
> https://github.com/postgres/postgres/blob/master/src/pl/plpgsql/src/pl_exec.c#L8304
> Not sure what the implication is there.

Yeah, that's some more unfinished business.  I'm not sure if it
matters to your use-case or not.

BTW, we probably should move this thread to pgsql-hackers.

            regards, tom lane



pgsql-general by date:

Previous
From: Michel Pelletier
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql
Next
From: user
Date:
Subject: Fwd: Postgres attach partition: AccessExclusive lock set on different tables depending on how attaching is performed