Re: Transition tables for triggers on foreign tables and views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Transition tables for triggers on foreign tables and views
Date: 2017-04-28 19:42:46
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> On Tue, Apr 25, 2017 at 6:17 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> For views, aside from the question of transition tables, I noticed
>> that statement triggers don't seem to fire at all with updatable
>> views. Surely they should -- isn't that a separate bug?

> I checked out 25dc142a (before any of my commits for $subject),
> built it, and tried the above -- with no warning generated. I then
> used an UPDATE and DELETE against the view, also with no trigger
> fired (nor any error during trigger creation or DML). Does anyone
> know whether such trigger ever fired at any point in the commit
> history?

[ experiments... ] They did, and do, fire if you do it the old-style
way with an INSTEAD OF row trigger. They don't fire if you're relying
on an updatable view. It seems we fire the table's statement triggers
instead, ie, the update is fully translated into an update on the
underlying table.

I'm not sure how intentional that was, but it's not a completely
unreasonable definition on its face, and given the lack of field
complaints since 9.3, I think we should probably stick to it.
However, if you didn't understand that from the documentation,
then we have a documentation problem.

> If we do get these working, don't they deserve at least
> one regression test?

Are you sure there isn't one?

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2017-04-28 20:39:41 Re: pgbench tap tests & minor fixes
Previous Message Robert Haas 2017-04-28 19:07:02 Re: Partition-wise join for join between (declaratively) partitioned tables