Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id E6D8F63245C for ; Mon, 19 Jan 2009 04:18:18 -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 42424-10 for ; Mon, 19 Jan 2009 04:18:12 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from dd1514.kasserver.com (dd1514.kasserver.com [85.13.128.107]) by mail.postgresql.org (Postfix) with ESMTP id A8E48632411 for ; Mon, 19 Jan 2009 04:18:12 -0400 (AST) Received: from [10.211.55.6] (exit.credativ.com [87.139.82.80]) by dd1514.kasserver.com (Postfix) with ESMTP id AC1AF1874122; Mon, 19 Jan 2009 09:18:08 +0100 (CET) Date: Mon, 19 Jan 2009 09:18:09 +0100 From: Bernd Helmle To: Peter Eisentraut cc: pgsql-hackers@postgresql.org Subject: Re: WIP: Automatic view update rules Message-ID: In-Reply-To: <49711FCB.7060404@gmx.net> 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> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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/1362 X-Sequence-Number: 132006 --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. Opinions? -- Thanks Bernd