Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tw2PE-00067T-3W for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2013 03:14:12 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1Tw2PD-0005mI-Kk for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2013 03:14:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tw2PC-0005mA-Jv for pgsql-hackers@postgresql.org; Fri, 18 Jan 2013 03:14:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Tw2PA-0000fy-Iv for pgsql-hackers@postgresql.org; Fri, 18 Jan 2013 03:14:10 +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 r0I3E42S024063; Thu, 17 Jan 2013 22:14:04 -0500 (EST) From: Tom Lane To: Andres Freund cc: Dimitri Fontaine , Simon Riggs , Robert Haas , Alvaro Herrera , PostgreSQL Hackers Subject: Re: Event Triggers: adding information In-reply-to: <20130118030124.GI3074@awork2.anarazel.de> References: <16675.1358454278@sss.pgh.pa.us> <18941.1358462151@sss.pgh.pa.us> <20130118013334.GE3074@awork2.anarazel.de> <23579.1358477281@sss.pgh.pa.us> <20130118030124.GI3074@awork2.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 18 Jan 2013 04:01:25 +0100" Date: Thu, 17 Jan 2013 22:14:04 -0500 Message-ID: <24062.1358478844@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 Andres Freund writes: > On 2013-01-17 21:48:01 -0500, Tom Lane wrote: >> If we're only interested in replication, let's put in some hooks whose >> contract does not allow for side-effects on the local catalogs, and be >> done. Otherwise we'll be putting in man-years of unnecessary (or at >> least unnecessary for this use-case) work. > Its a thing of perspective I guess. I can't imagine a hook-ey solution, > without quite a bit of work, that gets enough information to regenerate > SQL that performs the same action on another system. ISTM that the > refactoring to make that consistently "easy" is the hard part, but I > hope I am wrong. The problem of how to get the information needed is real and large, I agree. But that's not any easier for a trigger --- if anything, it's probably harder, because then you not only need to *get* the information but you have to figure out how to provide it in a way that makes sense at SQL level. 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