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-29 03:56:18 |
Message-ID: | 15145.1493438178@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)gmail(dot)com> writes:
> Well, I was sort of hoping that the triggers that can now be defined
> but can never fire *did* fire at some point.
They will fire if you have an INSTEAD OF row-level trigger; the existence
of that trigger is what determines whether we implement DML on a view
through the view's own triggers or through translation to an action on
the underlying table.
I do not think it'd be reasonable to throw an error for creation of
a statement-level view trigger when there's no row-level trigger,
because that just imposes a hard-to-deal-with DDL ordering dependency.
You could make a case for having the updatable-view translation code
print a WARNING if it notices that there are statement-level triggers
that cannot be fired due to the translation.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2017-04-29 04:33:49 | Re: some review comments on logical rep code |
Previous Message | Tom Lane | 2017-04-29 03:39:40 | Re: convert EXSITS to inner join gotcha and bug |