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