Why prepared statements is not busted after other used objects are re-created (table, function)?
Obviously, in such cases, the prepared statement is re-parsed before execute it again.
The similar behavior was expected for types.
Rashid Abzalov <rashid.abzalov@gmail.com> writes:
> Steps to reproduce:
> *1)* Create type and function:
> create type pg_temp.temp_type AS (field varchar(64));
> create function pg_temp.test_func(param pg_temp.temp_type) returns
> temp_type as $$
> begin
> param.field = 'qqq';
> return param;
> end;
> $$ language plpgsql;
> *2)* Prepare and use them:
> PREPARE testplan (pg_temp.temp_type) AS
> select * from pg_temp.test_func($1);
> EXECUTE testplan(('(qqq)')::pg_temp.temp_type);
> *3)* Drop type and function:
> drop function pg_temp.test_func(param pg_temp.temp_type);
> drop type pg_temp.temp_type;
So at this point you've deleted the type that is declared to be the
argument type of the prepared statement. I don't think "reparse" is what
is called for here. The prepared statement is busted and we shouldn't be
willing to execute it anymore. As indeed we don't, though I'll grant you
that "cache lookup failed" is not the world's best error message for that.
If prepared statements were full-fledged database objects, we could
imagine hooking them into the DROP CASCADE logic so that you couldn't drop
the type without (implicitly or explicitly) doing "DEALLOCATE testplan".
I doubt anyone will care to do that though, as it'd make them far
heavier-weight than they are now.
My inclination, if we do anything at all about this, is just to add
something like
if (!SearchSysCacheExists1(TYPEOID, ObjectIdGetDatum(expected_type_id)))
ereport(ERROR, ... "prepared statement's argument type no longer exists");
in EvaluateParams. But I can't get too excited about that.
regards, tom lane