On 2015-04-02 16:42:43 -0400, Peter Eisentraut wrote: > On 4/2/15 11:50 AM, Dean Rasheed wrote: > > Well actually the fact that the code is structured that way is > > somewhat academic. INSTEAD OF triggers on views don't support WHEN > > conditions -- deliberately so, since it would be difficult to know in > > general what to do if the trigger didn't fire. So ExecInsert is > > implicitly using the existence of the trigger to imply that it will > > fire, although arguably it would be neater for it to double-check > > that, and error out if for some reason the trigger didn't fire. In any > > case, that doesn't establish any kind of behavioural precedent for how > > a conditional INSTEAD OF trigger on a table ought to work. > > I think the upshot is that INSTEAD OF triggers work in a particular way > because that's what is needed to support updatable views. If triggers > on tables should behave differently, maybe it should be a separate > trigger type. Maybe it would be feasible to extend BEFORE triggers to > support RETURNING, for example?
What in the above prohibits extending the behaviour to tables? I have yet to see what compatibility or similarity problem that'd pose. It seems all mightily handwavy to me. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
