| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Aliouii Ali <aliouii(dot)ali(at)aol(dot)fr>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Tables cannot have INSTEAD OF triggers |
| Date: | 2015-04-02 20:42:43 |
| Message-ID: | 551DA9C3.7010306@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/2/15 11:50 AM, Dean Rasheed wrote:
> 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.
I think the upshot is that INSTEAD OF triggers work in a particular way
because that's what is needed to support updatable views. If triggers
on tables should behave differently, maybe it should be a separate
trigger type. Maybe it would be feasible to extend BEFORE triggers to
support RETURNING, for example?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2015-04-02 20:57:14 | Re: Table-level log_autovacuum_min_duration |
| Previous Message | Robert Haas | 2015-04-02 20:35:37 | Re: extend pgbench expressions with functions |