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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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