Re: Added schema level support for publication.
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Rahila Syed <rahilasyed90@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-15T09:46:48Z
Lists: pgsql-hackers
Thanks Rahila for your comments, please find my thoughts below. On Tue, Jan 12, 2021 at 5:16 PM Rahila Syed <rahilasyed90@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 <vignesh21@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
Commits
-
Include schema/table publications even with exclude options in dump.
- 4aa6fa3cd0a2 18.0 landed
-
Rename some enums to use TABLE instead of REL.
- b3812d0b9bcf 15.0 landed
-
Add tap tests for the schema publications.
- 6b0f6f79eef2 15.0 landed
-
Allow publishing the tables of schema.
- 5a2832465fd8 15.0 landed
-
In pg_dump, use simplehash.h to look up dumpable objects by OID.
- 92316a4582a5 15.0 cited