Re: Statement-level triggers and inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Statement-level triggers and inheritance
Date: 2008-12-01 17:09:28
Message-ID: 22919.1228151368@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
> However, I strongly lean towards the behavior in this case being to only
> fire the parent statement-level trigger. I could support the other way as
> well: I'm not going to add any triggers to the children anyway, so as long
> as the parent fires, I'll be happy. Right now, this is a serious bug for
> my app, as there is no INSERT INTO ONLY syntax, and thus there is no way
> to effect a statement-level trigger using an insert on a table that is
> inherited from. My workaround is to insert and then update all the rows.

You're not making a lot of sense here, because INSERT always affects
exactly the named table. It's UPDATE and DELETE where the behavior
is debatable.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-01 17:10:15 Re: Re: [COMMITTERS] pgsql: Add support for matching wildcard server certificates to the new
Previous Message Hitoshi Harada 2008-12-01 16:13:50 Re: Windowing Function Patch Review -> Standard Conformance