> 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?
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 Hertroys||Date: 2008-06-26 17:13:26|
|Subject: Re: ERROR: could not open relation with OID 2836|
|Previous:||From: Ludwig Kniprath||Date: 2008-06-26 16:43:23|
|Subject: Re: Windows Crash|