On 8 November 2012 14:38, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 8 November 2012 08:33, Dean Rasheed <dean.a.rash...@gmail.com> wrote: >> OK, yes I think we do need to be throwing the error at runtime rather >> than at plan time. That's pretty easy if we just keep the current >> error message... > > Oh wait, that's nonsense (not enough caffeine). The rewrite code needs > to know whether there are INSTEAD OF triggers before it decides > whether it's going to substitute the base relation. The fundamental > problem is that the plans with and without triggers are completely > different, and there's no way the executor is going to notice the > addition of triggers if they weren't there when the query was > rewritten and planned. >
In fact doesn't the existing plan invalidation mechanism already protect us from this? Consider for example: create table foo(a int); create view foo_v as select a+1 as a from foo; create function foo_trig_fn() returns trigger as $$ begin insert into foo values(new.a-1); return new; end $$ language plpgsql; create trigger foo_trig instead of insert on foo_v for each row execute procedure foo_trig_fn(); Then I can do: prepare f(int) as insert into foo_v values($1); PREPARE execute f(1); INSERT 0 1 drop trigger foo_trig on foo_v; DROP TRIGGER execute f(2); ERROR: cannot insert into view "foo_v" DETAIL: Views with columns that are not simple references to columns in the base relation are not updatable. HINT: You need an unconditional ON INSERT DO INSTEAD rule or an INSTEAD OF INSERT trigger. create trigger foo_trig instead of insert on foo_v for each row execute procedure foo_trig_fn(); CREATE TRIGGER execute f(3); INSERT 0 1 Regards, Dean -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
