marko@joh.to writes:
> I hit the behaviour on 9.1 originally with functions, but tested it against
> a reasonably fresh HEAD and it was still broken. Somehow it seems that the
> prepared statement isn't willing to forget the data type of the argument
> after it has been resolved once (even though it was specified to be unknown
> :-( ). This leads to some grotesque cache invalidation code in our API.
I'm not exactly convinced that this is a bug. Having a prepared statement
silently change its input parameter types seems a lot more dangerous than
just failing; especially since we lack any signaling mechanism by which
the client application could be warned that whatever it may have known
about the statement is now invalid.
For largely the same reason, we don't allow a prepared statement to
change output column types:
regression=# create table tt (f1 int);
CREATE TABLE
regression=# insert into tt values(1);
INSERT 0 1
regression=# prepare foo as select * from tt;
PREPARE
regression=# execute foo;
f1
----
1
(1 row)
regression=# alter table tt alter column f1 type real;
ALTER TABLE
regression=# execute foo;
ERROR: cached plan must not change result type
I'm not sure why we would think that changing input parameter types is any
safer.
regards, tom lane
