Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nnzL1-0002H3-9E for pgsql-hackers@arkaria.postgresql.org; Mon, 09 May 2022 09:05:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nnzL0-0006ym-1A for pgsql-hackers@arkaria.postgresql.org; Mon, 09 May 2022 09:05:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nnzKz-0006yd-8M for pgsql-hackers@lists.postgresql.org; Mon, 09 May 2022 09:05:53 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nnzKv-0002VS-6p for pgsql-hackers@lists.postgresql.org; Mon, 09 May 2022 09:05:52 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3F34B5C0132; Mon, 9 May 2022 05:05:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 09 May 2022 05:05:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1652087147; x=1652173547; bh=AWp1cbupsHaRD1TnrzOmyYq3aVyD 2JwPdVJo+/MDO0c=; b=VUkehju5zEPCtdILjD6x2yrgGOsHhbQCkH5aGeU5V9UW TJi5pEAm96OTGgZBCSeVs25aDEBiefJ8mqUfLey8CQD6pdvFgbu0ZSFc+IX40yoc u2NDHb8i7sVfCMsJ/Q+3IvFOrVHVeJc+rXY9ckylR+LWfCKSf6ZDaaUJW6o3CTsp 6z0wqaChtiPAlcSRvU0myB4CAB1+9ZdaZA60pfhsa2qYOaD7hCJYuV5qTrzraToN o2qtnFa/3VPOs5OH9uyraDIx3u13LHDAmpTFYxUesl6CHVrMUgi3dj31P2gHzGmx E7jhRxInGxLvjqcwpow757+rxogIbw7mG86GMaa7Cw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeelgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeejkeff gfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 May 2022 05:05:46 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 8E6DC2A09B1; Mon, 9 May 2022 11:05:12 +0200 (CEST) Date: Mon, 9 May 2022 11:05:12 +0200 From: Alvaro Herrera To: Dilip Kumar Cc: Amit Kapila , Zheng Li , PostgreSQL Hackers , rajesh singarapu , Ajin Cherian , =?utf-8?B?SG91LCBaaGlqaWUv5L6vIOW/l+adsA==?= Subject: Re: Support logical replication of DDLs Message-ID: <202205090905.bjca3mtbeqcd@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-May-08, Dilip Kumar wrote: > On Sat, May 7, 2022 at 9:38 AM Amit Kapila wrote: > > I agree that it adds to our maintainability effort, like every time we > > enhance any DDL or add a new DDL that needs to be replicated, we > > probably need to change the deparsing code. But OTOH this approach > > seems to provide better flexibility. So, in the long run, maybe the > > effort is worthwhile. I am not completely sure at this stage which > > approach is better but I thought it is worth evaluating this approach > > as Alvaro and Robert seem to prefer this idea. > > +1, IMHO with deparsing logic it would be easy to handle the mixed DDL > commands like ALTER TABLE REWRITE. But the only thing is that we will > have to write the deparsing code for all the utility commands so there > will be a huge amount of new code to maintain. Actually, the largest stumbling block on this, IMO, is having a good mechanism to verify that all DDLs are supported. The deparsing code itself is typically not very bad, as long as we have a sure way to twist every contributor's hand into writing it, which is what an automated test mechanism would give us. The code in test_ddl_deparse is a pretty lame start, not nearly good enough by a thousand miles. My real intention was to have a test harness that would first run a special SQL script to install DDL capture, then run all the regular src/test/regress scripts, and then at the end ensure that all the DDL scripts were properly reproduced -- for example transmit them to another database, replay them there, and dump both databases and compare them. However, there were challenges which I no longer remember and we were unable to complete this, and we are where we are. Thanks for rebasing that old code, BTW. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/