Re: Added schema level support for publication. - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Added schema level support for publication.
Date
Msg-id 4fb39707-dca9-1563-4482-b7a8315c36ca@enterprisedb.com
Whole thread Raw
In response to Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Added schema level support for publication.  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Added schema level support for publication.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Added schema level support for publication.  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
On 13.08.21 04:59, Amit Kapila wrote:
>> Even if we drop all tables added to the publication from it, 'pubkind'
>> doesn't go back to 'empty'. Is that intentional behavior? If we do
>> that, we can save the lookup of pg_publication_rel and
>> pg_publication_schema in some cases, and we can switch the publication
>> that was created as FOR SCHEMA to FOR TABLE and vice versa.
>>
> Do we really want to allow users to change a publication that is FOR
> SCHEMA to FOR TABLE? I see that we don't allow to do that FOR TABLES.
> postgres=# Alter Publication pub add table tbl1;
> ERROR:  publication "pub" is defined as FOR ALL TABLES
> DETAIL:  Tables cannot be added to or dropped from FOR ALL TABLES publications.

I think the strict separation between publication-for-tables vs. 
publication-for-schemas is a mistake.  Why can't I have a publication 
that publishes tables t1, t2, t3, *and* schemas s1, s2, s3.  Also note 
that we have a pending patch to add sequences support to logical 
replication.  So eventually, a publication will be able to contain a 
bunch of different objects of different kinds.



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?
Next
From: Simon Riggs
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?