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

From Amit Kapila
Subject Re: Added schema level support for publication.
Date
Msg-id CAA4eK1JRZOFNm6mQtOJmb7VXycfZqEZk5eRSccFk65xyMVqmUA@mail.gmail.com
Whole thread Raw
In response to RE: Added schema level support for publication.  ("tanghy.fnst@fujitsu.com" <tanghy.fnst@fujitsu.com>)
Responses Re: Added schema level support for publication.  (Tom Lane <tgl@sss.pgh.pa.us>)
RE: Added schema level support for publication.  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
List pgsql-hackers
On Mon, Sep 13, 2021 at 7:06 PM tanghy.fnst@fujitsu.com
<tanghy.fnst@fujitsu.com> wrote:
>
> 6.
> I think if I use 'ALTER PUBLICATION ... SET', both the list of tables and the
> list of all tables in schemas should be reset. The publication should only
> contain the tables and all tables in schemas which user specified. If user only
> specified all tables in schema, and didn't specify tables, the tables which used
> to be part of the publication should be dropped, too. But currently, if I didn't
> specify tables, the list of tables wouldn't be set to empty. Thoughts?
>

I think we can go either way here but it seems like we should drop the
tables in the case you mentioned. The idea is that the SET variant in
ALTER PUBLICATION should replace the set of tables and schemas for the
publication which seems to be in line with the current behavior where
we replace the set of tables.

Anyone else wants to weigh in on this?

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: resowner module README needs update?
Next
From: Tom Lane
Date:
Subject: Re: postgres.h included from relcache.h - but removing it breaks pg_upgrade