Re: Using Expanded Objects other than Arrays from plpgsql
| От | Michel Pelletier |
|---|---|
| Тема | Re: Using Expanded Objects other than Arrays from plpgsql |
| Дата | |
| Msg-id | CACxu=vLXvpzN4X3k+9jsMt6ujuOvFVUSkA80t_cROSsF4y2jQQ@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-general |
On Sun, Oct 20, 2024 at 10:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I'm not sure. It seems certain that if the object is already expanded
(either R/W or R/O), the paths for that in plpgsql_exec_function could
be taken regardless of its specific type.
But it seems like we could get an easy win by adjusting
plpgsql_exec_function along the lines of
l. 549:
- if (!var->isnull && var->datatype->typisarray)
+ if (!var->isnull)
l. 564:
- else
+ else if (var->datatype->typisarray)
How far does that improve matters for you?
I tried this change and couldn't get it to work, on the next line:
if (!var->isnull)
{
if (VARATT_IS_EXTERNAL_EXPANDED_RW(DatumGetPointer(var->value)))
{
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.
I guess this gets back into knowing if a flat thing is expandable or not. I'm going to spend some more time looking at it, I haven't been in this corner of Postgres before.
Another comment that caught my eye was this one:
Not sure what the implication is there.
-Michel
В списке pgsql-general по дате отправления: