Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TwKBG-0004OL-A6 for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2013 22:12:58 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TwKBF-0008OM-6x for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Jan 2013 22:12:57 +0000 Received: from makus.postgresql.org ([98.129.198.125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TwKBE-0008OH-2E for pgsql-hackers@postgresql.org; Fri, 18 Jan 2013 22:12:56 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TwKBD-0003re-2i for pgsql-hackers@postgresql.org; Fri, 18 Jan 2013 22:12:55 +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 r0IMCnrU004374; Fri, 18 Jan 2013 17:12:49 -0500 (EST) From: Tom Lane To: Robert Haas cc: Alvaro Herrera , Andres Freund , Dimitri Fontaine , Simon Riggs , PostgreSQL Hackers Subject: Re: Event Triggers: adding information In-reply-to: References: <20130118013334.GE3074@awork2.anarazel.de> <20130118140721.GA29501@alap2.anarazel.de> <20130118154732.GE29501@alap2.anarazel.de> <20130118170857.GK29501@alap2.anarazel.de> <10183.1358531053@sss.pgh.pa.us> <20130118180326.GM29501@alap2.anarazel.de> <20130118182255.GG4063@alvh.no-ip.org> <11782.1358535557@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Fri, 18 Jan 2013 16:41:31 -0500" Date: Fri, 18 Jan 2013 17:12:49 -0500 Message-ID: <4373.1358547169@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: > On Fri, Jan 18, 2013 at 1:59 PM, Tom Lane wrote: >> Well, that burden already exists for non-utility statements --- why >> should utility statements get a pass? Other than that we tend to invent >> new utility syntax freely, which might be a good thing to discourage >> anyhow. > My concerns are that (1) it will slow down the addition of new > features to PostgreSQL by adding yet another barrier to commit and (2) > it won't be get enough use or regression test coverage to be, or > remain, bug-free. Meh. The barriers to inventing new statements are already mighty tall. As for (2), I agree there's risk of bugs, but what alternative have you got that is likely to be less bug-prone? At least a reverse-list capability could be tested standalone without having to set up a logical replication configuration. This should not be interpreted as saying I'm gung-ho to do this, mind you. I'm just saying that if our intention is to support logical replication of all DDL operations, none of the alternatives look cheap. 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