Re: Converting plpgsql to use DTYPE_REC for named composite types

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).

> 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.

> 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".

regards, tom lane