2017-12-29 18:38 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > 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). > > 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 >
