Re: Converting plpgsql to use DTYPE_REC for named composite types

2017-12-29 18:38 GMT+01:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 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?
>
> That's something I expect we can improve in followon patches, but
> it seems a bit outside the scope of this patch (which is mighty
> big already).
>
>
ok

> > Because PLPGSQL_NSTYPE_ROW is removed, then "switch" statement is maybe
> > useless
>
> I'd just as soon leave it as a switch, for possible future expansion.
>

I don't think so there will be some cases - but it is not a issue

> > why is in exec_assign_value still case for PLPGSQL_DTYPE_ROW ?
>
> Take it out and see ;-). The whole point of having DTYPE_ROW
> at all is to support stuff like "SELECT ... INTO a,b,c".
>

ok

Regards

Pavel

> regards, tom lane
>