X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 2DD135382F
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon,  2 May 2005 04:58:20 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 54069-05
	for <pgsql-sql-postgresql.org@localhost.postgresql.org>;
	Mon,  2 May 2005 07:58:16 +0000 (GMT)
Received: from fzkmail2.fzk.de (fzkmail2.fzk.de [141.52.27.52])
	by svr1.postgresql.org (Postfix) with SMTP id 3DC9253B16
	for <pgsql-sql@postgresql.org>; Mon,  2 May 2005 04:58:14 -0300 (ADT)
Received: FROM resy5.fzk.de BY fzkmail2.fzk.de ;
 Mon May 02 09:58:06 2005 +0200
Received: from rodos.fzk.de (resy6.fzk.de [141.52.68.10])
	by resy5.fzk.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id
	j427w5sG011580; Mon, 2 May 2005 09:58:05 +0200
Message-ID: <4275DD8C.EF29E7A1@rodos.fzk.de>
Date: Mon, 02 May 2005 09:58:04 +0200
From: Christoph Haller <ch@rodos.fzk.de>
X-Mailer: Mozilla 4.77 [en] (X11; U; HP-UX B.10.20 9000/780)
X-Accept-Language: en
MIME-Version: 1.0
To: weigelt@metux.de
Cc: pgsql-sql <pgsql-sql@postgresql.org>
Subject: Re: trigger/rule question
References: <20050427165624.GA4253@nibiru.borg.metux.de>
	<4270AC4F.6D62C9C8@rodos.fzk.de>
	<20050502034100.GE24546@nibiru.borg.metux.de>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS - amavis-milter (http://www.amavis.org/)
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.026 tagged_above=0 required=5 tests=AWL
X-Spam-Level: 
X-Archive-Number: 200505/11
X-Sequence-Number: 21324

Enrico Weigelt wrote:
> 
> * Christoph Haller <ch@rodos.fzk.de> wrote:
> 
> Hi,
> 
> > I assume this still refers to
> > [SQL] RULE for mtime recording
> > from last Friday.
> 
> ehm, yeah. I forgot that I've already asked this stuff ...
> hmmpf. seems I'm not getting younger ;-)
> 
> <snip>
> > I gave it another thought and
> > I am now having something which seems to work.
> > The trick is interpose a view to avoid the
> > rule recursion:
> 
> <big_snip />
> 
> correct me if I'm wrong:
> 
> you dont let the application write to the actual storage table, but
> instead to a view, which a modified write to the actual storage, where
> also the reads get their data from.

Exactly. 
> 
> okay, that's really an idea worth to think about :)
> 
> insert should work the same way. but how to implement delete ?
> (the application should only see one table, so in our case the view).

Exactly. 
> if we user "DO INSTEAD", we wont get anything to delete (AFAIK), so
> we cannot intercept here. the only chance seems to leave out "INSTEAD"
> and live with duplicate data.

No. What's wrong with (referring to my previous post) 

CREATE OR REPLACE RULE joo_delete 
AS ON DELETE TO joo_view 
DO INSTEAD 
DELETE FROM joo 
WHERE bar = OLD.bar ; 

DELETE FROM joo_view WHERE bar = '...' ; 

works perfectly for me 

Or did I miss something here? 
Regards, Christoph 

> 
> Did I miss anyting ?
> 
> cu
> --
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service
>   phone:     +49 36207 519931         www:       http://www.metux.de/
>   fax:       +49 36207 519932         email:     contact@metux.de
> ---------------------------------------------------------------------
>   Realtime Forex/Stock Exchange trading powered by postgresSQL :))
>                                             http://www.fxignal.net/
> ---------------------------------------------------------------------
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
>                http://archives.postgresql.org