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 1nm6Pu-0006IH-5a for pgsql-hackers@arkaria.postgresql.org; Wed, 04 May 2022 04:15:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nm6Ps-0004ay-QD for pgsql-hackers@arkaria.postgresql.org; Wed, 04 May 2022 04:15:08 +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 1nm6Ps-0004ap-FC for pgsql-hackers@lists.postgresql.org; Wed, 04 May 2022 04:15:08 +0000 Received: from mail-yb1-xb34.google.com ([2607:f8b0:4864:20::b34]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nm6Pq-0003xd-Cf for pgsql-hackers@lists.postgresql.org; Wed, 04 May 2022 04:15:08 +0000 Received: by mail-yb1-xb34.google.com with SMTP id s30so458060ybi.8 for ; Tue, 03 May 2022 21:15: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=f4VNDoqfGevx6Ei+yTNjs30ZtfKeMC/+mQtATVF2480=; b=KQRDhRcpOc+3mprNIT885jTx3Y9TP4TeKZQJ+fKqip/pFrydTVCWP40+XsY0X3Pshd qN14+p9yWG0Sg1fr49mYFws5gnop/Wf42AaXAd++3n+rP/lRQQqUpho0w6yX8bDwn3IK LQzTvbPveksPh6LndqSawa8w/dNK4xXDWTCmsNshWiYbnO8t4+KxDkTW6yXzJ8SbJy45 0u+XHpG9VZ2sERlWm3SYfCw5qef27cSLoqjBKFpczp1ADFF68oDd+DsFuiCzyfqTtDRj SM3eZorBKt+WoUwhOQUlTmDWDVZSW1iSVGFdcnkEMP6rPk1wb6EUkrH/1w/oOax6j2OH 2nkg== 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=f4VNDoqfGevx6Ei+yTNjs30ZtfKeMC/+mQtATVF2480=; b=xQsSvJNNfY9120n2rYvqTiX0c6eYAJ2Bx4DENqaAVlAg1ufAelr5N7v4Azd+cwC2QQ olr66oQIc7cNaTRu+7AqGAhM2n1jqiAsEV3J1TXrFpSOPFQTlj4L3SyVL122IU4LJZey B+f0DMEWk6xwKPNf0FTVWnNUryAcithpTVb77Kdmtk2tRfKNjoQv3vulBOC1xaL6r4fW XMe4gq/T9GHThGDg1xIF3DO6sBN+0e7z9yzzkI+4hiHs+Ccs4wZnhIofGj+l2pDLbdYR GByeVs1UTdBXT6I+/v6n0hseBQpZZbnfqiodLsimMKbdh5CI31f6Ik2ZOq9wsapXsuKR UsBA== X-Gm-Message-State: AOAM532yqLf1tv7hugtzj1RF4z1deDprzVcbCDMxtoG+y24Yzr7805eZ 4M0PwRlpfR14msHncMN1Zdev5e2tX9pDQnxG2Io= X-Google-Smtp-Source: ABdhPJyIvngkdf4KI5h5w/nPseFzPsxCU1hKf+5SQ4FqD5WGv6SjgZs/lCHZGFXNHjTAW++5qPwC0rSg/8Xhw1K1MmY= X-Received: by 2002:a25:7b84:0:b0:648:f212:1baf with SMTP id w126-20020a257b84000000b00648f2121bafmr16264312ybc.578.1651637704231; Tue, 03 May 2022 21:15:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 4 May 2022 09:44:53 +0530 Message-ID: Subject: Re: Skipping schema changes in publication To: Peter Smith Cc: Bharath Rupireddy , 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 Tue, May 3, 2022 at 2:24 PM Peter Smith wrote: > > On Thu, Apr 28, 2022 at 9:32 PM Amit Kapila wrote: > > > ... > > 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. > > > > Consider if the user does > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE t1,t2; > ALTER PUBLICATION pub1 ADD ALL TABLES EXCEPT t3,t4; > > What does it mean? > e.g. Is there only one exception list that is modified? Or did the ADD > ALL TABLES override all meaning of the original list? > e.g. Are we now skipping t1,t2,t3,t4, or are we now only skipping t3,t4? > This won't be allowed. We won't allow changing ALL TABLES publication unless the user first performs RESET. This is the purpose of providing the RESET variant. > ~~~ > > Here is a similar example, where the ADD TABLE seems confusing to me > when it intersects with a prior EXCEPT > e.g. > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT t1,t2; // ok > ALTER PUBLICATION pub1 ADD TABLE t1; ??? > > What does it mean? > e.g. Does the explicit ADD TABLE override the original exception list? > e.g. Is t1 published now or should that ALTER have caused an error? > This won't be allowed either. We don't allow to Add/Drop from All Tables publication unless the user performs a RESET. This is true even today except that we don't have a RESET syntax. > ~~ > > It feels like there are too many tricky rules when using EXCEPT with > ALTER PUBLICATION. I guess complexities can be described in the > documentation but IMO it would be better if the ALTER syntax could be > unambiguous in the first place. > Agreed. > So perhaps the rules should be more > restrictive (e.g. just disallow ALTER ... ADD any table that overlaps > the existing EXCEPT list ??) > I think the current proposal seems to be restrictive enough to avoid any tricky issues. Do you see any other problem? -- With Regards, Amit Kapila.