Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id D36396324A1 for ; Mon, 19 Jan 2009 05:39:32 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 26789-10 for ; Mon, 19 Jan 2009 05:39:23 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mail.postgresql.org (Postfix) with SMTP id ACC73632265 for ; Mon, 19 Jan 2009 05:39:21 -0400 (AST) Received: (qmail invoked by alias); 19 Jan 2009 09:39:19 -0000 Received: from gmp-ea-fw-1.sun.com (EHLO dhcp-eesp05-101-40.Finland.Sun.COM) [192.18.1.36] by mail.gmx.net (mp035) with SMTP; 19 Jan 2009 10:39:19 +0100 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX19zrfBwEtBzwTdoCmZekcsRmXZ3tiRMN4Zwm1xDsV uuvWiGgM+r3Ecb Message-ID: <49744A3B.1060606@gmx.net> Date: Mon, 19 Jan 2009 11:39:07 +0200 From: Peter Eisentraut User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bernd Helmle CC: pgsql-hackers@postgresql.org Subject: Re: WIP: Automatic view update rules References: <2849137C693B65CC8E86411C@imhotep.credativ.de> <94CF655A8D0DC7D5B4B81D8B@imhotep.credativ.de> <603c8f070811112006q906b3a6o59a66228b7fc997@mail.gmail.com> <7F84532C73CB3279DE8436E0@imhotep.credativ.de> <603c8f070811131344n5c087057p11f94780dae80885@mail.gmail.com> <603c8f070811252043r75db3e83v2eba1611452ee62e@mail.gmail.com> <3073cc9b0812250943x23547116ud956d8ab111e55bf@mail.gmail.com> <61043.91.48.33.48.1230474598.squirrel@tooney.at.xencon.de> <3B3B2ACA2DB4AF9AF585FBAF@teje> <0163DD949AF0457BB1DBBD80@teje> <496B3C2E.6040908@gmx.net> <566CB90F49AFDB29D12D3D21@teje> <49711FCB.7060404@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/1364 X-Sequence-Number: 132008 Bernd Helmle wrote: > --On Samstag, Januar 17, 2009 02:01:15 +0200 Peter Eisentraut > wrote: > >> * It is not clear how automatic rules and manual DO ALSO rules should >> interact. A manual DO ALSO rule will currently clear out an automatic >> INSTEAD rule, which I find to be illogical. > > My intentional feeling was that it would be a bad idea to leave any > implicit rule when someone is going to create his own rule set on a > view, at least to avoid any confusion or side effects. Consider someone > having his own rules upgrading from an older version. He must have at > least his own DO INSTEAD Rule, it doesn't make any sense to have his own > DO ALSO Rule without an INSTEAD one. Thus, doing it this way will leave > the view as expected from the original setup. > > *thinking more*...if we teach explicit DO ALSO rules *not* to clean out > implicit ones, we will have the following workflows: > > a) View is updatable, has its own automatic DO INSTEAD rule: if someone > is restoring his old update rules, he will have at least his own DO > INSTEAD rule. This will drop any corresponding automatically created > rule, adding his own DO INSTEAD rule and any DO ALSO rule. > > b) View is updatable, has its own automatic DO INSTEAD rule: The user is > able to create any additional DO ALSO rule. > > I don't see any problems here, as long as the implicit DO INSTEAD rule > gets replaced. Someone who previously had a DO INSTEAD rule to effect updatable views as well as a DO ALSO rule to create some side effect (e.g., auditing/logging), will after the upgrade perhaps want to rely on the automatic view update rules but will still want to create his own DO ALSO rule. In the current patch, the creation of the DO ALSO rule will delete the automatic view update rules, thus breaking the entire scenario. Considering that the updatable views feature deals only with DO INSTEAD rules, we should leave DO ALSO rules completely alone.