Re: DO INSTEAD and conditional rules - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: DO INSTEAD and conditional rules
Date
Msg-id 426ED6A3.4080204@Yahoo.com
Whole thread Raw
In response to Re: DO INSTEAD and conditional rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: DO INSTEAD and conditional rules
List pgsql-hackers
On 4/26/2005 5:58 PM, Tom Lane wrote:
> David Wheeler <david@kineticode.com> writes:
>> No, you can have multiple queries--you just have to understand that 
>> those that come first might have an effect on those that come later.
> 
> ... which indeed can be a feature, not a bug, depending on what you're
> doing ...
> 
>             regards, tom lane

There is no such thing as a free lunch here. If one wants a row inserted 
by one action being visible by a subsequent one, then a delete done in 
another action must (by default) be visible to subsequent actions as 
well. I don't think that fiddling with scan-command-ID's on top of the 
rule definitions will make the average user understand them easier.

The multi-action rules usually come into play when someone attempts to 
make join-views updatable. Not an easy problem, granted, but most of the 
time I have found a combination of rules together with ON UPDATE/DELETE 
CASCADE constraints or even user defined triggers absolutely sufficient. 
The INSERT and UPDATE case is handled by rules as usual. And in the 
DELETE case the rule just deletes the critical rows and the ON DELETE 
CASCADE constraints do the rest.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: John DeSoi
Date:
Subject: Re: [PATCHES] Continue transactions after errors in psql
Next
From: Rod Taylor
Date:
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?