Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TozIK-0006oz-2J for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Dec 2012 16:29:56 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TozIJ-0005GR-F9 for pgsql-hackers@arkaria.postgresql.org; Sat, 29 Dec 2012 16:29:55 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TozIH-0005Ey-BP for pgsql-hackers@postgresql.org; Sat, 29 Dec 2012 16:29:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TozIG-0004UL-5U for pgsql-hackers@postgresql.org; Sat, 29 Dec 2012 16:29:52 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id qBTGTnpn011135; Sat, 29 Dec 2012 11:29:49 -0500 (EST) From: Tom Lane To: Robert Haas cc: Dimitri Fontaine , PostgreSQL Hackers Subject: Re: Event Triggers: adding information In-reply-to: References: Comments: In-reply-to Robert Haas message dated "Sat, 29 Dec 2012 07:48:36 -0500" Date: Sat, 29 Dec 2012 11:29:49 -0500 Message-ID: <11134.1356798589@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Robert Haas writes: > The other danger here is - what exactly do you mean by "no command has > been able to run between the user command and our lookup"? Because > you can do stupid things with functions like set_config(). This would > only be safe if no user-provided expressions can possibly get > evaluated between point A and point B, and that strikes me as the sort > of thing that could easily be false unless this is all done VERY close > to the start of processing. To me, the largest single risk of the whole event triggers feature is precisely that it will result in random user-provided code getting executed in fairly random places, thus breaking assumptions of this type that may be hard or impossible to fix. But given that allowing that is more or less exactly the point of the feature, I'm not sure why you're blaming the patch for it. It should have been rejected on day one if you're not willing to have that type of risk. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers