X-Original-To: pgsql-sql@postgresql.org
Received: from spampd.localdomain (postgresql.org [64.49.215.8])
	by postgresql.org (Postfix) with ESMTP id 2EBB8475A4B
	for <pgsql-sql@postgresql.org>; Mon, 24 Mar 2003 12:31:42 -0500 (EST)
Received: from mired.org (ip68-97-54-220.ok.ok.cox.net [68.97.54.220])
	by postgresql.org (Postfix) with SMTP id 4347F474E44
	for <pgsql-sql@postgresql.org>; Mon, 24 Mar 2003 12:31:41 -0500 (EST)
Received: (qmail 92335 invoked from network); 24 Mar 2003 17:31:46 -0000
Received: from localhost.mired.org (HELO guru.mired.org) (127.0.0.1)
	by localhost.mired.org with SMTP; 24 Mar 2003 17:31:46 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15999.16641.828710.981313@guru.mired.org>
Date: Mon, 24 Mar 2003 11:31:45 -0600
To: Christoph Haller <ch@rodos.fzk.de>
Cc: pgsql-sql@postgresql.org
Subject: Re: Rule for updating through a view.
In-Reply-To: <3E7F2C01.E012A174@rodos.fzk.de>
References: <3E7F2C01.E012A174@rodos.fzk.de>
X-Mailer: VM 7.07 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;
	h9L,Yg`+vb1>RG% 	*h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\
From: Mike Meyer <mwm@mired.org>
X-Delivery-Agent: TMDA/0.71 (Hoop, Jr.)
X-Spam-Status: No, hits=-15.5 required=5.0 tests=BAYES_10,IN_REP_TO,REFERENCES
	autolearn=ham	version=2.50
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp)
X-Archive-Number: 200303/553
X-Sequence-Number: 12591

In <3E7F2C01.E012A174@rodos.fzk.de>, Christoph Haller <ch@rodos.fzk.de> typed:
> Is it this what you've found and can't get to work?

Yes, that was what I found. I was having trouble figuring out how it
*should* work. I think I've got it now - the missing idea was that the
new and old rows contain the *entire* rows, not just what was being
updated. That makes it possible to pull values from them and udpate
entire rows in the table(s) the view joins. At least, that's the way I
believe it should work. My views don't have enough information to
identify a unique row in those tables, so I can't do this safely
anyway.

	Thanks,
	<mike
-- 
Mike Meyer <mwm@mired.org>		http://www.mired.org/consulting.html
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.