RE: Skipping schema changes in publication - Mailing list pgsql-hackers

From shiy.fnst@fujitsu.com
Subject RE: Skipping schema changes in publication
Date
Msg-id TYAPR01MB6315FF450C5D10253BA7C7FFFDD19@TYAPR01MB6315.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
Responses Re: Skipping schema changes in publication  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On Sat, May 14, 2022 9:33 PM vignesh C <vignesh21@gmail.com> wrote:
> 
> Thanks for the comments, the attached v5 patch has the changes for the
> same. Also I have made the changes for SKIP Table based on the new
> syntax, the changes for the same are available in
> v5-0002-Skip-publishing-the-tables-specified-in-EXCEPT-TA.patch.
>

Thanks for your patch. Here are some comments on v5-0001 patch.

+        Oid            relid = lfirst_oid(lc);
+
+        prid = GetSysCacheOid2(PUBLICATIONRELMAP, Anum_pg_publication_rel_oid,
+                               ObjectIdGetDatum(relid),
+                               ObjectIdGetDatum(pubid));
+        if (!OidIsValid(prid))
+            ereport(ERROR,
+                    (errcode(ERRCODE_UNDEFINED_OBJECT),
+                     errmsg("relation \"%s\" is not part of the publication",
+                            RelationGetRelationName(rel))));

I think the relation in the error message should be the one whose oid is
"relid", instead of relation "rel".

Besides, I think it might be better not to report an error in this case. If
"prid" is invalid, just ignore this relation. Because in RESET cases, we want to
drop all tables in the publications, and there is no specific table.
(If you agree with that, similarly missing_ok should be set to true when calling
PublicationDropSchemas().)

Regards,
Shi yu

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: bogus: logical replication rows/cols combinations
Next
From: Natarajan R
Date:
Subject: Valgrind mem-check for postgres extension