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 1mvm61-0006bC-SW for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Dec 2021 20:02:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mvm5z-0006zN-AQ for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Dec 2021 20:02:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvm5y-0006zE-1O for pgsql-hackers@lists.postgresql.org; Fri, 10 Dec 2021 20:02:19 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mvm5v-0007Yd-6A for pgsql-hackers@postgresql.org; Fri, 10 Dec 2021 20:02:16 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CC1D93201F1D; Fri, 10 Dec 2021 15:02:12 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 10 Dec 2021 15:02:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XrlXd8S/YCFDYwKqJXq5JIL+HFVgJ7t3RBsrxD/j/t8=; b=Rm9xjJtQ vYhun/mmSvTx4tUEllDOHZu0zEsAWOQqCZiDCXcUe0n4YvbFmxyLw2Q6QM1o9N9H 79QXz+n9dV3NXqZtP/4abOdE0ewsebeKyzz1eWaQGqiwK+wevh6fU/aF4stZckO7 gY7xZ/zbwdIQwTdIPDXp4+sEDfFEDzZHE34CvpRttHBYHZKMdQBlzpnnIQdIkYFK XoOxgFQari4EeJbq6qCLEStk8xP4BVq7J6IzXAyMCUAeVSbG756zfdggkPWsiec8 bLJUAkK/g+sTfxBWpXMKx/jsLUSWSSA2bMTlPRmGU6l24EnW0pAZDrlkj6M274hE bPTx0yrfG+3HAw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkedvgddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpedujeevjeffjeevuddutedvkeeiueeitddvieelfeekveej udefgeeuvdejhfeuleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 10 Dec 2021 15:02:11 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 7E95E2A075D; Fri, 10 Dec 2021 17:02:08 -0300 (-03) Date: Fri, 10 Dec 2021 17:02:08 -0300 From: Alvaro Herrera To: Rahila Syed Cc: Amit Kapila , Tomas Vondra , Peter Smith , PostgreSQL-development Subject: Re: Column Filtering in Logical Replication Message-ID: <202112102002.pejiewltbf3c@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <202109020849.ql6bqpcecpxh@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-Sep-02, Alvaro Herrera wrote: > On 2021-Sep-02, Rahila Syed wrote: > > > After thinking about this, I think it is best to remove the entire table > > from publication, > > if a column specified in the column filter is dropped from the table. > > Hmm, I think it would be cleanest to give responsibility to the user: if > the column to be dropped is in the filter, then raise an error, aborting > the drop. Then it is up to them to figure out what to do. I thought about this some more and realized that our earlier conclusions were wrong or at least inconvenient. I think that the best behavior if you drop a column from a table is to remove the column from the publication column list, and do nothing else. Consider the case where you add a table to a publication without a column filter, and later drop the column. You don't get an error that the relation is part of a publication; simply, the subscribers of that publication will no longer receive that column. Similarly for this case: if you add a table to a publication with a column list, and later drop a column in that list, then you shouldn't get an error either. Simply the subscribers of that publication should receive one column less. Should be fairly quick to implement ... on it now. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "The problem with the facetime model is not just that it's demoralizing, but that the people pretending to work interrupt the ones actually working." (Paul Graham)