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

Re: DO INSTEAD and conditional rules

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Wheeler <david(at)kineticode(dot)com>,Rob Butler <crodster2k(at)Yahoo(dot)com>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>,Neil Conway <neilc(at)samurai(dot)com>
Subject: Re: DO INSTEAD and conditional rules
Date: 2005-04-27 00:02:43
Message-ID: 426ED6A3.4080204@Yahoo.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 4/26/2005 5:58 PM, Tom Lane wrote:
> David Wheeler <david(at)kineticode(dot)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(at)Yahoo(dot)com #

In response to

Responses

pgsql-hackers by date

Next:From: Rod TaylorDate: 2005-04-27 00:16:32
Subject: Re: [PERFORM] Bad n_distinct estimation; hacks suggested?
Previous:From: John DeSoiDate: 2005-04-27 00:02:30
Subject: Re: [HACKERS] Continue transactions after errors in psql

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