Re: rule's behavior with join interesting

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Richard Huxton <dev(at)archonet(dot)com>
Cc: Kemin Zhou <kemin(dot)zhou(at)ferring(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: rule's behavior with join interesting
Date: 2004-04-22 19:57:45
Message-ID: 408823B9.8020608@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Richard Huxton wrote:
> On Wednesday 21 April 2004 21:07, Kemin Zhou wrote:
>> Here I have a very simple case
>>
>> table1
>> table1_removed
>>
>> anotherTable
>>
>> create or replace RULE rec_remove as ON DELETE TO table1
>> do insert into table1_remove
>> select old.*, a.acc from old g join anotherTable a on g.acc=a.other_acc;
>> ===
>> the parser complained ERROR: relation "*OLD*" does not exist
>> So I used
>> select old.*, a.acc from table1 g join anotherTable a on g.acc=a.other_acc;
>>
>> This worked find.
>>
>> When I run delete on table1, 213 rows.
>>
>> tmp table received 213X213 = 45369 rows. each row is duplicated 213 times.
>
> The issue here is that although you can refer to values such as OLD.acc, OLD
> is not a table but more like single row. So, you probably want
> ...DO INSERT INSTO table1_remove
> SELECT old.*, a.acc FROM anotherTable a WHERE a.other_acc = OLD.acc;

Old is not a single row at all, it is a placeholder for the result set
that is deleted in this case. The rule you probably want is:

create rule rec_remove as on delete to table1
do insert into table1_remove select old.*, a.acc
from anotherTable a where old.acc = a.other_acc;

This unfortunately does NOT support all the other join types, since the
parser does not let you use JOIN before any FROM and you have old
already in your rangetable, even if you don't see it.

Jan

>
> Your second example just ignored the OLD.acc altogether in the join, so of
> course you got an unconstraind join of 213 x 213.

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

Browse pgsql-sql by date

  From Date Subject
Next Message Federico Pedemonte 2004-04-22 20:09:54 Re: staggered query?
Previous Message Dennis 2004-04-22 19:29:32 lifetime of temp schema versus compiled image of plpgsql proc