Re: Tables cannot have INSTEAD OF triggers
От | Andres Freund |
---|---|
Тема | Re: Tables cannot have INSTEAD OF triggers |
Дата | |
Msg-id | 20150402210211.GG17586@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Tables cannot have INSTEAD OF triggers (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Tables cannot have INSTEAD OF triggers
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: