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 #
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 |