Re: Converting plpgsql to use DTYPE_REC for named composite types - Mailing list pgsql-hackers

Pavel Stehule <pavel.stehule@gmail.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