Re: Added schema level support for publication.

Thanks Rahila for your comments, please find my thoughts below.

On Tue, Jan 12, 2021 at 5:16 PM Rahila Syed <rahilasyed90(at)gmail(dot)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(at)gmail(dot)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