From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Converting plpgsql to use DTYPE_REC for named composite types
In-reply-to: 
 <CAFj8pRAwGmqgg+uA4k1iiQhm29ADQ5g1czpw1u1=M2qBZRq-sg@mail.gmail.com>
References: <8962.1514399547@sss.pgh.pa.us>
 <CAFj8pRB1y_RY1pN99CAr9i3Z2c8vbjonRkEqGBnVaFxvLx6Tfw@mail.gmail.com>
 <CAFj8pRAwGmqgg+uA4k1iiQhm29ADQ5g1czpw1u1=M2qBZRq-sg@mail.gmail.com>
Comments: In-reply-to Pavel Stehule <pavel.stehule@gmail.com>
	message dated "Fri, 29 Dec 2017 18:26:25 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25346.1514569089.1@sss.pgh.pa.us>
Date: Fri, 29 Dec 2017 12:38:09 -0500
Message-ID: <25347.1514569089@sss.pgh.pa.us>
Precedence: bulk

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