Re: Skipping schema changes in publication

On Mon, Jan 19, 2026 at 3:08 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> Approaches for Supporting EXCEPT in Partitioned Tables
> ------------------------------------------------------------------------
>
> In an offline discussion with Peter Smith, Amit, and Shlok, we
> identified several approaches for supporting EXCEPT with partitioned
> tables and their partitions. I’d like to hear others’ opinions on
> these approaches.
>
> Consider the following partition hierarchy:
> tab_root
> ├─ tab_part_1
> │ ├─ tab_part_1_p1
> │ └─ tab_part_1_p2
> └─ tab_part_2
> ├─ tab_part_2_p1
> └─ tab_part_2_p2
>
>
> Approach 1:
> ---------------------------------
> If we exclude a table, then the data in that table and all of its
> partitions (i.e., the entire subtree under that table) should not be
> replicated.
>
> For example EXCEPT (tab_part_1) skips replication of tab_part_1 and
> all of its partitions.
>
> This behaviour remains the same with or without
> publish_via_partition_root. The publish_via_partition_root flag only
> affects publish_via_relid, i.e., the relation through which data is
> published.
>
> This approach involves certain implementation challenges. For brevity,
> these are documented in the attached 'Approach1_challenges' document.
>
> Approach 2:
> ---------------------------------------------------
> Assign meaning to ONLY and '*' for partition tables in the EXCEPT
> list. In HEAD, ONLY and '*' do not have any meaning for partitioned
> tables or partitions, and these keywords are currently ignored.
>
> Examples:
> 1. EXCEPT (ONLY tab_part_1) skips replication of only the table
> tab_part_1. Changes for tab_root, tab_part_1_p1, and tab_part_1_p2 are
> still replicated.
>
> ii. EXCEPT (tab_part_1*) skips replication of tables tab_part_1,
> tab_part_1_p1, and tab_part_1_p2
>
> The challenges described in Approach 1, particularly around tablesync
> handling and COPY behaviour, would still need to be addressed under
> this approach as well. ONLY or '*' with partitioned tables is not
> supported in HEAD, supporting it specifically for ALL TABLES EXCEPT
> may introduce additional confusion for users.
>
> Approach 3:
> ----------------
> Do not allow partitions to be specified in the EXCEPT clause.
>
> Only EXCEPT (tab_root) is supported, which excludes tab_root and all
> of its partitions. Specifying EXCEPT (tab_part_1) or EXCEPT
> (tab_part_1_p1) will result in an error.
>
> ~~
>
> While Approach 1 and Approach 2 offer more flexibility to the user
> compared to Approach 3, they also introduce additional design
> complexity which does not seem simpler to address.

Thanks for explaining this, overall I like the Approach 1, and I also
see the problem when publish via root is given in that case COPY FROM
is executed on the root and it would be hard to exclude specific
partitions. What is the behavior when root of partition tree is added
but publish via root is not true, it doesn't add any relation to
publication rel or how does it manage to not copy data from
partitions?

--
Regards,
Dilip Kumar
Google