Re: Tables cannot have INSTEAD OF triggers

On 2 April 2015 at 14:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Apr 1, 2015 at 1:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> It would absolutely *not* be reasonable for WHEN conditions for triggers
>>> on tables to work completely differently than they do for triggers on
>>> views. That ship's sailed.
>
>> Clue me in, because I'm confused. If no trigger fires, we do whatever
>> an object of that type would normally do in the absence of any
>> trigger, no? For a view, that's error out; for a table, that's
>> perform the action on the underlying data. That doesn't seem terribly
>> unprincipled.
>
> I dunno about unprincipled; but we have already laid down the definition
> of INSTEAD OF triggers, and they act as I described. Read the code if you
> doubt it: which path is taken in ExecInsert depends only on whether
> INSTEAD OF triggers *exist* on the rel, not whether any of them actually
> fired (indeed, it would be difficult even to know that from here).
> I believe this was intentional, not just a coding artifact; it stems from
> having wanted to throw the error for uninsertable view well upstream of
> here, rather than having it be conditional on what happens at runtime.
>
> What I am objecting to is Andres' claim that it would be okay for INSTEAD
> OF triggers on tables to act completely differently in this regard from
> those on views. We have laid down the definition for views, and it is
> that nothing happens if the trigger exists but doesn't fire.
>

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.

Regards,
Dean