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 4BD213A499C for ; Thu, 4 Nov 2004 22:24:05 +0000 (GMT) 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 48576-10 for ; Thu, 4 Nov 2004 22:23:49 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 7CE163A49B0 for ; Thu, 4 Nov 2004 22:23:50 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id iA4MNmJ7050156 for ; Thu, 4 Nov 2004 22:23:48 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id iA4MGQO7048242 for pgsql-sql@postgresql.org; Thu, 4 Nov 2004 22:16:26 GMT From: Mischa Sandberg Reply-To: ischamay.andbergsay@activestateway.com User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 X-Newsgroups: comp.databases.postgresql.sql Subject: CREATE TRIGGER ... FOR EACH STATEMENT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 16 Message-ID: <1Txid.94791$9b.89312@edtnps84> Date: Thu, 04 Nov 2004 22:16:29 GMT To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.7 tagged_above=0.0 required=5.0 tests=LINES_OF_YELLING, NO_DNS_FOR_FROM, SUBJ_ALL_CAPS X-Spam-Level: * X-Archive-Number: 200411/67 X-Sequence-Number: 19386 I notice a dearth of description of the FOR EACH STATEMENT flavour of triggers, even though OLD_TABLE and NEW_TABLE are mentioned. After years of Sybase & MSSQL, being able to deal with the entire INSERTED/DELETED rowsets in a trigger, rather than nibbling away row by row, has been a great efficiency boost. In fact, the only I've resorted to FOR EACH ROW triggers is where joining OLD_TABLE and NEW_TABLE by primary key burned the CPU --- both pseudo-tables being very large in some updates, and perforce having no indexes ... I can see from src/backend/command/trigger.c that ExecASInsertTriggers() would have a hard time getting at the equivalent of OLD_TABLE and NEW_TABLE, ExecBSInsertTriggers even worse. Anyone else out there who feels this would be a significant enhancement?