On Wed, Jan 22, 2020 at 2:38 PM Amit Langote <amitlangote09@gmail.com> wrote:
> Other than that, the updated patch contains following significant changes:
>
> * Changed pg_publication.c: GetPublicationRelations() so that any
> published partitioned tables are expanded as needed
>
> * Since the pg_publication_tables view is backed by
> GetPublicationRelations(), that means subscriptioncmds.c:
> fetch_table_list() no longer needs to craft a query to include
> partitions when needed, because partitions are included at source.
> That seems better, because it allows to limit the complexity
> surrounding publication of partitioned tables to the publication side.
>
> * Fixed the publication table DDL to spot more cases of tables being
> added to a publication in a duplicative manner. For example,
> partition being added to a publication which already contains its
> ancestor and a partitioned tables being added to a publication
> (implying all of its partitions are added) which already contains a
> partition
On second thought, this seems like an overkill. It might be OK after
all for both a partitioned table and its partitions to be explicitly
added to a publication without complaining of duplication. IOW, it's
the user's call whether it makes sense to do that or not.
> Only attaching 0001.
Attached updated 0001 considering the above and the rest of the
patches that add support for replicating partitioned tables using
their own identity and schema. I have reorganized the other patches
as follows:
0002: refactoring of logical/worker.c without any functionality
changes (contains much less churn than in earlier versions)
0003: support logical replication into partitioned tables on the
subscription side (allows replicating from a non-partitioned table on
publisher node into a partitioned table on subscriber node)
0004: support optionally replicating partitioned table changes (and
changes directly made to partitions) using root partitioned table
identity and schema
Thanks,
Amit