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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
