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 1nmF9p-0000Y9-0n for pgsql-hackers@arkaria.postgresql.org; Wed, 04 May 2022 13:35:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nmF9l-0005Kf-U9 for pgsql-hackers@arkaria.postgresql.org; Wed, 04 May 2022 13:35:05 +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 1nmF9l-0005Iu-Jj for pgsql-hackers@lists.postgresql.org; Wed, 04 May 2022 13:35:05 +0000 Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nmF9e-0003ve-Eg for pgsql-hackers@lists.postgresql.org; Wed, 04 May 2022 13:35:04 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5D3275C0219; Wed, 4 May 2022 09:34:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 04 May 2022 09:34:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references: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=1651671297; x=1651757697; bh=/B7GQDXKJD+hiV26LkJz2qz/xzVx 90dZn4CDpPeVfNE=; b=TcGV5i3M4/xCplnTgxqmQwl8Dx2fcMmaGwcq6BekSSCM JLO6QbMJhAH14Yor8Tw7M47cB8KYvyBPaZz7/TB5yi2/jW7OQ0v0CewD3KDs9s3a 4/2ayMosGfqMslvCWOn+ozGro+enbrMNCJnQukZGQWZlx4s9HfG/lDfKnN0aEqRp VUbY/gsIJvlh+qZGs8XKYGyeBNkZ+DAOqtsElUmoR7b6vEoNHDrAAVnD1zUpDTva Q7RQe2tOqgzDpob4bMvE15j9jlt6J0Ih7YZdFDYUKGckvfY8pQoMZ2TwDc0p7bmm c+/QvQxxd8yDToBZu48ux3v2hVVcv0ySTKKZXb+DlQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdelgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuhffvfhgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvghtvghr ucfgihhsvghnthhrrghuthcuoehpvghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrh hprhhishgvuggsrdgtohhmqeenucggtffrrghtthgvrhhnpeefgefgteefudehheduffev lefhkeeulefhfffgvdelgfffueduledtgfekiefhjeenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthes vghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 May 2022 09:34:55 -0400 (EDT) Message-ID: <4f4867da-f581-0330-974f-da9031ac3e1c@enterprisedb.com> Date: Wed, 4 May 2022 15:34:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: Skipping schema changes in publication Content-Language: en-US From: Peter Eisentraut To: vignesh C , PostgreSQL Hackers References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 14.04.22 15:47, Peter Eisentraut wrote: > That said, I'm not sure this feature is worth the trouble.  If this is > useful, what about "whole database except these schemas"?  What about > "create this database from this template except these schemas".  This > could get out of hand.  I think we should encourage users to group their > object the way they want and not offer these complicated negative > selection mechanisms. Another problem in general with this "all except these" way of specifying things is that you need to track negative dependencies. For example, assume you can't add a table to a publication unless it has a replica identity. Now, if you have a publication p1 that says includes "all tables except t1", you now have to check p1 whenever a new table is created, even though the new table has no direct dependency link with p1. So in more general cases, you would have to check all existing objects to see whether their specification is in conflict with the new object being created. Now publications don't actually work that way, so it's not a real problem right now, but similar things could work like that. So I think it's worth thinking this through a bit.