Skip site navigation (1) Skip section navigation (2)

Re: what are rules for?

From: Dean Rasheed <dean_rasheed(at)hotmail(dot)com>
To: Michael Shulman <shulman(at)mathcamp(dot)org>
Cc: <pgsql-general(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <kleptog(at)svana(dot)org>,<adam(dot)r(at)sbcglobal(dot)net>
Subject: Re: what are rules for?
Date: 2008-06-26 17:11:02
Message-ID: BAY102-W21E9E33CE98FD758C637EF2A30@phx.gbl (view raw, whole thread or download thread mbox)
Lists: pgsql-general
> On Thu, Jun 26, 2008 at 5:08 AM, Dean Rasheed  wrote:
>> The Oracle "instead of" trigger ducks this issue completely. The
>> trigger is called once per row in the view that matches the top-level
>> "where" clause, and it is entirely up to the author of the trigger
>> function to work out what to update (if anything).
> That sounds like exactly the sort of thing I was envisioning.
> Although from what Tom said, it sounds as though "instead of" triggers
> in PostgreSQL would have to be implemented in a significantly
> different way from other triggers.
> How does an Oracle "instead of" trigger decide how many rows to tell
> the caller were updated?  Can this "return value" be modified
> programmatically by the trigger?
> Mike

AFAIK Oracle's "instead of" trigger has no mechanism for returning the
actual number of rows updated (the trigger itself has no return value). So
I guess that they are just assuming that it matches the number of times
the trigger was executed, and returning that to the caller.

This can almost be implemented in PostgreSQL right now, using a rule of
the form "... do instead select trigger_fn()" - except, as you point out, the
caller won't know how many rows were actually updated. As far as the
top-level query knows, it didn't update anything, which will break some
(most?) clients. Apart from that, this does actually work!



In response to


pgsql-general by date

Next:From: Alban HertroysDate: 2008-06-26 17:13:26
Subject: Re: ERROR: could not open relation with OID 2836
Previous:From: Ludwig KniprathDate: 2008-06-26 16:43:23
Subject: Re: Windows Crash

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group