Обсуждение: 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