Re: Allow WHEN in INSTEAD OF triggers

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Allow WHEN in INSTEAD OF triggers
Date: 2019-12-28 16:29:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Dec 27, 2019 at 10:29:15PM -0500, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > While noodling around with an upcoming patch to remove user-modifiable
> > RULEs, I noticed that WHEN conditions were disallowed from INSTEAD OF
> > triggers for no discernible reason. This patch removes that
> > restriction.
> This seems like a remarkably bad idea. The point of an INSTEAD OF
> trigger is that it is guaranteed to handle the operation. What's
> the system supposed to do with rows the trigger doesn't handle?

Nothing. Why would it be different from the other forms of WHEN in

> I notice that your patch doesn't even bother to test what happens,
> but I'd argue that whatever it is, it's wrong. If you think that
> "do nothing" or "throw an error" is appropriate, you can code that
> inside the trigger. It's not PG's charter to make such a decision.

If that's the case, why do we have WHEN for triggers at all? I'm just
working toward make them more consistent. From a UX perspective, it's
a lot simpler and clearer to do this in the trigger declaration than
it is in the body.

> PS: I think your chances of removing rules are not good, either.

I suspect I have a lot of company in my view of user-modifiable
rewrite rules as an experiment we can finally discontinue in view of
its decisive results.

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres:

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2019-12-28 16:45:30 Re: Allow WHEN in INSTEAD OF triggers
Previous Message Tomas Vondra 2019-12-28 16:03:27 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions