Thanks Rahila for your comments, please find my thoughts below. On Tue, Jan 12, 2021 at 5:16 PM Rahila Syed <rahilasye...@gmail.com> wrote: > > Hi Vignesh, > > I had a look at the patch, please consider following comments. > > On Thu, Jan 7, 2021 at 10:03 PM vignesh C <vignes...@gmail.com> wrote: >> >> Hi, >> >> This feature adds schema option while creating publication. Users will >> be able to specify one or more schemas while creating publication, >> when the user specifies schema option, then the data changes for the >> tables present in the schema specified by the user will be replicated >> to the subscriber. Few examples have been listed below: >> >> Create a publication that publishes all changes for all the tables >> present in production schema: >> CREATE PUBLICATION production_publication FOR ALL TABLES SCHEMA production; >> > Should it be FOR TABLES IN SCHEMA instead of FOR ALL TABLES SCHEMA? >
For adding tables into publication we have syntax like: CREATE PUBLICATION mypub FOR TABLE tbl1, tbl2; For all tables we have syntax like: CREATE PUBLICATION mypub FOR ALL TABLES; Initial syntax that I proposed was: CREATE PUBLICATION production_publication *FOR ALL TABLES SCHEMA* production; I feel the below syntax is better, as it is consistent with others: CREATE PUBLICATION mypub *FOR SCHEMA* sch1, sch2; >> >> Create a publication that publishes all changes for all the tables >> present in marketing and sales schemas: >> CREATE PUBLICATION sales_publication FOR ALL TABLES SCHEMA marketing, sales; >> >> Add some schemas to the publication: >> ALTER PUBLICATION sales_publication ADD SCHEMA marketing_june, sales_june; >> > As per current implementation this command fails even if one of the schemas does not > exist. I think this is counterintuitive, it should throw a warning and continue adding the rest. > We have the similar behavior in case of adding non-existent table while creating a publication: CREATE PUBLICATION mypub3 FOR TABLE non_existent_table; ERROR: relation "non_existent_table" does not exist I feel we can keep the behavior similarly to maintain the consistency. >> >> Drop some schema from the publication: >> ALTER PUBLICATION production_quarterly_publication DROP SCHEMA production_july; >> > Same for drop schema, if one of these schemas does not exist in publication, > the entire DROP operation is aborted. We have similar behavior in case of dropping non-existent table while altering publication alter publication mypub5 drop table test1,testx; ERROR: relation "testx" does not exist I feel we can keep the behavior similarly to maintain the consistency. Regards, Vignesh EnterpriseDB: http://www.enterprisedb.com
