Обсуждение: cached plan issue in trigger func

I thought we had fixed this in 8.3:
   cap=# create table t1 (t varchar(40));   CREATE TABLE   cap=# create table t2 (t varchar(40));   CREATE TABLE
cap=#create function t1trig() returns trigger language plpgsql as   $$ begin insert into t2 values(new.t); return null;
end;$$;   CREATE FUNCTION   cap=# create trigger t1trigger after insert on t1 for each row   execute procedure
t1trig();  CREATE TRIGGER   cap=# insert into t1 values('a');   INSERT 184789343 1   cap=# alter table t1 alter column
ttype text;   ALTER TABLE   cap=# alter table t2 alter column t type text;   ALTER TABLE   cap=# insert into t1
values('b');  ERROR:  type of "new.t" does not match that when preparing the plan   CONTEXT:  PL/pgSQL function
"t1trig"line 1 at SQL statement   cap=#
 



cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> I thought we had fixed this in 8.3:

I think that behavior is intentional: plancache.c can deal with the plan
changing internally, but it doesn't expect that its callers could
survive the plan's argument datatypes changing underneath them.
        regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>   
>> I thought we had fixed this in 8.3:
>>     
>
> I think that behavior is intentional: plancache.c can deal with the plan
> changing internally, but it doesn't expect that its callers could
> survive the plan's argument datatypes changing underneath them.
>   

How do we reconcile that with this advertised feature of 8.3?:

  * Automatically re-plan cached queries when table definitions change    or statistics are updated


How is a user to know when s/he can rely on this and when they can't? I 
at least was expecting the plan to be invalidated by the table changes.


cheers

andrew