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
