Re: Converting plpgsql to use DTYPE_REC for named composite types

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
Date: 2017-12-29 17:26:25
Message-ID: CAFj8pRAwGmqgg+uA4k1iiQhm29ADQ5g1czpw1u1=M2qBZRq-sg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

2017-12-29 9:56 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

> Hi
>
> I'll stick this into the January commitfest, but I'd like to get it
>> reviewed and committed pretty soon, because there are follow-on patches
>> that need to get done in time for v11 --- in particular, we need to close
>> out the lack of plpgsql support for domains-over-composite.
>>
>>
> I didn't checked code - just I did some performance tests and I am
> thinking so performance is very good.
>
> Master's record type has 50% speed of row type in my test. Patched has +/-
> same speed.
>
> I see very small slowdown for row type .. about 3% but I think so it is
> acceptable - I tested some worst case.
>
> Unfortunately - it breaks and very breaks all plpgsql related extensions -
> pldebug, plprofiler, plpgsql_check. On second hand, there are only few
> extensions of this kind.
>
>
I checked the code:

Interesting part from test:

alter table mutable drop column f1;
alter table mutable add column f1 float8;
-- currently, this fails due to cached plan for "r.f1 + 1" expression
select sillyaddone(42);
ERROR: type of parameter 4 (double precision) does not match that when
preparing the plan (integer)
CONTEXT: PL/pgSQL function sillyaddone(integer) line 1 at RETURN

In this case, can we invalidate plan cache? It can decrease a risk of
runtime issues when tables are altered.

Because PLPGSQL_NSTYPE_ROW is removed, then "switch" statement is maybe
useless

if (ns != NULL && nnames == 2)
{
switch (ns->itemtype)
{
case PLPGSQL_NSTYPE_REC:
{
/*
* words 1/2 are a record name, so third word could
be
* a field in this record.
*/
PLpgSQL_rec *rec;
PLpgSQL_recfield *new;

rec = (PLpgSQL_rec *) (plpgsql_Datums[ns->itemno]);
new = plpgsql_build_recfield(rec, word3);

wdatum->datum = (PLpgSQL_datum *) new;
wdatum->ident = NULL;
wdatum->quoted = false; /* not used */
wdatum->idents = idents;
return true;
}

default:
break;
}
}
}

should be reduced

if (ns != NULL && nnames == 2 && ns->itemtype ==
PLPGSQL_NSTYPE_REC)
{
/*
* words 1/2 are a record name, so third word could
be
* a field in this record.
*/
PLpgSQL_rec *rec;
PLpgSQL_recfield *new;

rec = (PLpgSQL_rec *) (plpgsql_Datums[ns->itemno]);
new = plpgsql_build_recfield(rec, word3);

wdatum->datum = (PLpgSQL_datum *) new;
wdatum->ident = NULL;
wdatum->quoted = false; /* not used */
wdatum->idents = idents;
return true;
}

why is in exec_assign_value still case for PLPGSQL_DTYPE_ROW ?

Regards

Pavel

> Regards
>
> Pavel
>
>
> regards, tom lane
>>
>>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-12-29 17:33:24 Re: [HACKERS] taking stdbool.h into use
Previous Message Tom Lane 2017-12-29 17:19:16 Re: Possible hole in Windows directory restrictions?