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 1oOgUI-0001Pn-Cw for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Aug 2022 14:27: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 1oOgUH-0007M5-Ad for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Aug 2022 14:27:09 +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 1oOgUH-0007Lw-1j for pgsql-hackers@lists.postgresql.org; Thu, 18 Aug 2022 14:27:09 +0000 Received: from mail-oi1-x235.google.com ([2607:f8b0:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oOgUE-0000hb-RG for pgsql-hackers@lists.postgresql.org; Thu, 18 Aug 2022 14:27:08 +0000 Received: by mail-oi1-x235.google.com with SMTP id s199so1710960oie.3 for ; Thu, 18 Aug 2022 07:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=QTfmML9iy05N5/oF/RLuLwlyX+dfz1myFUJKWxnSWMg=; b=SjHEz43LLMWz87q61P5A91XiY6/onp3PLoWYdgJjpysSa8ZKxN/IQv0DAKXZRAmhIN ABKFY2XbopJJFq1VYNCl/mXqAq29btc9FB/OF3kjICOxn4MBRrS7R2weVn7DvmWaiDk+ TKQL88Ahh79EIV4b2BuNLEJ+wxQIwzdxSbcvfN+uUIAkvbTG35TX8CP0eA9FOa7odbXG 6DMFiWa83/IpVomsMLUVBIesO0BhFJM7q4rCNjnX7bmZL/8OpHoc7AwFooGPgKb1C5Qh djnZpHV8Z1jOjDp2TehL9IegX5t6vm2UJ3He18qVpwyrTOuTv+3zABHdZB1o7tLGdHB3 K00A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=QTfmML9iy05N5/oF/RLuLwlyX+dfz1myFUJKWxnSWMg=; b=gzWaYQ2vU085fU4VUeMhMBqgk3jtOpo+WnFVKZKm7A8PcKYy+ARafNZK+AzijlebpG C6drdXZ4ZDFhKTL5xiU9tyGMjE2AYgYckhsKYCt7bDbESbbtn0liFRDXINXGdJ7tMpWi oKOWyNwRUWijtPioxkBEbnCpQd6Mt5CBTznV7lK334+qMsO8nBp8B/PcEBPOFbGp4xlB iCEhayIbjAt0ijjetJe2JVZvOJTaxMgQJG5GrdX+IiEQXF8WTDy6KiypWut8xF81J28o 8HgqmAbI5Ljflmlyd7T0tr+L5ErhJpEae4Va+YV26KO+wdK2JJCkjnnE8o4fXou2MTh3 V6uQ== X-Gm-Message-State: ACgBeo0Tcx/PL8q2bcWSJz6IO+uCOHlxNt3w5ub+z09hfULF6fCj8kQ6 KvK20iOxaYyGkVDoMTEtRZuHEmgpEYmI7iIWirU= X-Google-Smtp-Source: AA6agR487jMMcCL+neon/bm5SOf5uDgrvcHmOCbd5ICzsvP49kOYDr6VN75LssbA0uQ/YBEGEnW55L0wo9HLiMx2UcE= X-Received: by 2002:a05:6808:1412:b0:342:ff44:6e5d with SMTP id w18-20020a056808141200b00342ff446e5dmr3883679oiv.160.1660832826055; Thu, 18 Aug 2022 07:27:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Thu, 18 Aug 2022 19:56:54 +0530 Message-ID: Subject: Re: Skipping schema changes in publication To: Nitin Jadhav Cc: "osumi.takamichi@fujitsu.com" , Peter Smith , Amit Kapila , Bharath Rupireddy , 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 Thu, Aug 18, 2022 at 12:33 PM Nitin Jadhav wrote: > > I spent some time on understanding the proposal and the patch. Here > are a few comments wrt the test cases. > > > +ALTER PUBLICATION testpub_reset ADD TABLE pub_sch1.tbl1; > > + > > +-- Verify that tables associated with the publication are dropped after RESET > > +\dRp+ testpub_reset > > +ALTER PUBLICATION testpub_reset RESET; > > +\dRp+ testpub_reset > > > > +ALTER PUBLICATION testpub_reset ADD ALL TABLES IN SCHEMA public; > > + > > +-- Verify that schemas associated with the publication are dropped after RESET > > +\dRp+ testpub_reset > > +ALTER PUBLICATION testpub_reset RESET; > > +\dRp+ testpub_reset > > The results for the above two cases are the same before and after the > reset. Is there any way to verify that? If you see the expected, first \dRp+ command includes: +Tables: + "pub_sch1.tbl1" The second \dRp+ does not include the Tables. We are trying to verify that after reset, the tables will be removed from the publication. The second test is similar to the first, the only difference here is that we test schema instead of tables. i.e we verify that the schemas will be removed from the publication. > --- > > > +-- Can't add EXCEPT TABLE to 'FOR ALL TABLES' publication > > +ALTER PUBLICATION testpub_reset ADD ALL TABLES EXCEPT TABLE pub_sch1.tbl1; > > + > > > > +-- Can't add EXCEPT TABLE to 'FOR TABLE' publication > > +ALTER PUBLICATION testpub_reset ADD ALL TABLES EXCEPT TABLE pub_sch1.tbl1; > > + > > > > +-- Can't add EXCEPT TABLE to 'FOR ALL TABLES IN SCHEMA' publication > > +ALTER PUBLICATION testpub_reset ADD ALL TABLES EXCEPT TABLE pub_sch1.tbl1; > > + > > I did not understand the objective of these tests. I think we need to > improve the comments. There are different publications like "ALL TABLES", "TABLE", "ALL TABLES IN SCHEMA" publications. Here we are trying to verify that except tables cannot be added to "ALL TABLES", "TABLE", "ALL TABLES IN SCHEMA" publications. If you see the expected file, you will see the following error: +-- Can't add EXCEPT TABLE to 'FOR ALL TABLES' publication +ALTER PUBLICATION testpub_reset ADD ALL TABLES EXCEPT TABLE pub_sch1.tbl1; +ERROR: adding ALL TABLES requires the publication to have default publication parameter values +DETAIL: ALL TABLES flag should not be set and no tables/schemas should be associated. +HINT: Use ALTER PUBLICATION ... RESET to reset the publication I felt the existing comment is ok. Let me know if you still feel any change is required. Regards, Vignesh