On 2 April 2015 at 14:59, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Apr 1, 2015 at 1:56 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
