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?