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 1nk2Na-0005IA-Dj for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Apr 2022 11:32:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nk2NZ-0004Ds-1y for pgsql-hackers@arkaria.postgresql.org; Thu, 28 Apr 2022 11:32:13 +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 1nk2NY-0004Dj-N1 for pgsql-hackers@lists.postgresql.org; Thu, 28 Apr 2022 11:32:12 +0000 Received: from mail-yw1-x1133.google.com ([2607:f8b0:4864:20::1133]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nk2NS-0000Yk-7X for pgsql-hackers@lists.postgresql.org; Thu, 28 Apr 2022 11:32:12 +0000 Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso49429137b3.5 for ; Thu, 28 Apr 2022 04:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8n06TQwCNDcrwN8rK8CStUKusg9JcmvvVef7dNI/x+g=; b=ahaBZMOmmcQCnwgE9IDbG3ihpO8VfvX0f+QBusKBSQQTIwGziTnjhSApe0Xla4LeTd Nwe1UaQMgRwN2yt+YiEEH4K2NE0CdH+HohvWWkXRj2gLOzQw72slgVcFa0Y3FjT4Gh5Z y5k9Dshq7xc5hdxUAQeG+BKVqobYg6z+YTuPU+7JCuTljvCQ9NA5yxLBipPsHIt4WCi5 7Ujm6febs+TGcl7JRgP5SRWVhaBN1Xy2ujcB0znNdaBt4sHuCudso9YcZCwOtVHM0Y/M zeXJqW6K6uddaa8/giXJczOtId6VigROuLGGn2m9V1aq2a+MNddKAYQzOa09i7oJVDfU jRzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8n06TQwCNDcrwN8rK8CStUKusg9JcmvvVef7dNI/x+g=; b=TNS8xLR4mrbTYtp1bIa3yzr0BJvHEeMKSRdXbBXqR21kzsleT1YOThj8AdaeyXpkzp Ty2qGe0LXhFaZz6OCkM9mxZT2A3R3enkVBwuGU1MXkfF1CMsI/Dm9hqqx4AU8YQs5cXl twrhnWgGatDeufo1dMb6VJBV6UcoP2x/ON8Re7qPRWcqtUGfWbqks+na3whrZE6/1QZa WFn8K4oAAKeyfBQckdlZv+igja3cmHOfWYEJCqFa0iUDjge0azPtfooOimDgwRX/r5WY qSklcuKXbRi9OUT8BkR9af7OEGuvlBWHozomkkTJm0MwwuwsM/E8AAHqEtAoJVNtEbZZ jCpw== X-Gm-Message-State: AOAM5336YPaaxwKkZCmoaEYoFhJGFrsGqfn3/qd65R0yAmfoN1zmMgaI kpuWBe0WxGu6UPkWUDeFpzxMVLT59T++8MG7/U2g0enOpTQ= X-Google-Smtp-Source: ABdhPJyycyI7/qL3pDo1X3StWMTNRpRkxbEvPGpdR736eEWdrrMyPWWEuvsGj4vSrd9gYg+BbjFwj5yKVcdhQn49QUw= X-Received: by 2002:a81:26c6:0:b0:2f4:c7b3:ad96 with SMTP id m189-20020a8126c6000000b002f4c7b3ad96mr33159856ywm.223.1651145524321; Thu, 28 Apr 2022 04:32:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Thu, 28 Apr 2022 17:01:53 +0530 Message-ID: Subject: Re: Skipping schema changes in publication To: Bharath Rupireddy Cc: vignesh C , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Apr 22, 2022 at 9:39 PM Bharath Rupireddy wrote: > > On Tue, Mar 22, 2022 at 12:39 PM vignesh C wrote: > > > > This feature adds an option to skip changes of all tables in specified > > schema while creating publication. > > This feature is helpful for use cases where the user wants to > > subscribe to all the changes except for the changes present in a few > > schemas. > > Ex: > > CREATE PUBLICATION pub1 FOR ALL TABLES SKIP ALL TABLES IN SCHEMA s1,s2; > > OR > > ALTER PUBLICATION pub1 ADD SKIP ALL TABLES IN SCHEMA s1,s2; > > > > The feature seems to be useful especially when there are lots of > schemas in a database. However, I don't quite like the syntax. Do we > have 'SKIP' identifier in any of the SQL statements in SQL standard? > After discussion, it seems EXCEPT is a preferred choice and the same is used in the other existing syntax as well. > Can we think of adding skip_schema_list as an option, something like > below? > > CREATE PUBLICATION foo FOR ALL TABLES (skip_schema_list = 's1, s2'); > ALTER PUBLICATION foo SET (skip_schema_list = 's1, s2'); - to set > ALTER PUBLICATION foo SET (skip_schema_list = ''); - to reset > Yeah, that is also an option but it seems it will be difficult to extend if want to support "all columns except (c1, ..)" for the column list feature. The other thing to decide is for which all objects we want to support EXCEPT clause as it may not be useful for everything as indicated by Peter E. and Euler. We have seen that Oracle supports "all columns except (c1, ..)" [1] and MySQL seems to support for tables [2]. I guess we should restrict ourselves to those two cases for now and then we can extend it later for schemas if required or people agree. Also, we should see the syntax we choose here should be extendable. Another idea that occurred to me today for tables this is as follows: 1. Allow to mention except during create publication ... For All Tables. CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE t1,t2; 2. Allow to Reset it. This new syntax will reset all objects in the publications. Alter Publication ... RESET; 3. Allow to add it to an existing publication Alter Publication ... Add ALL TABLES [EXCEPT TABLE t1,t2]; I think it can be extended in a similar way for schema syntax as well. [1] - https://dev.mysql.com/doc/refman/5.7/en/change-replication-filter.html [2] - https://docs.oracle.com/en/cloud/paas/goldengate-cloud/gwuad/selecting-columns.html#GUID-9A851C8B-48F7-43DF-8D98-D086BE069E20 -- With Regards, Amit Kapila.