Re: Skipping schema changes in publication

On Mon, Feb 9, 2026 at 11:52 AM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Sunday, February 8, 2026, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Mon, Feb 9, 2026 at 6:41 AM Peter Smith <smithpb2250@gmail.com> wrote:
>>
>> > Hi Amit.
>> >
>> > I understand there can be some tricky scenarios where partitions are
>> > involved, but I was not sure why "pub1: FOR ALL Tables EXCEPT (tab1)
>> > and pub2: FOR TABLE tab1" is an example of contradictory behaviour.
>> >
>> > Consider if the publisher has 3 tables tab1,tab2,tab3:
>> > Here, "pub1: FOR ALL Tables EXCEPT (tab1)" is like a shorthand for
>> > saying "pub1: FOR TABLE tab2,tab3"
>> > So what's wrong for the subscriber to combine pub1 and pub2 in this case?
>> >
>>
>> It is because one of the publications (pub2) indicates to include a
>> particular table tab1 and the other one (pub1) to exclude the same
>> table. And things become much more complex when the Except list
>> contains partitions as shown in Shveta's example. So, I think it makes
>> sense to keep things simple at least for the first version, we can
>> consider to uplift this restriction if we see some use cases from the
>> field.
>>
>>
>
> I’m with Peter here - I do not think it is wise to expose the exception listing outside the publication.  Publication combinations should be purely additive in much the same way grants are in the system.  Except lists are internal shorthand for describing the positive list of tables a publication makes available - all tables except.
>

The earlier case -
pub1: FOR ALL TABLES EXCEPT (tab1)
pub2: FOR TABLE tab1 WHERE (c = 99)

seems a valid scenario, and we are currently evaluating its
implementation feasibility under Approach 1.

OTOH, subscribing to two different publications that are both defined
as 'FOR ALL TABLES' but have different EXCEPT lists introduces
unnecessary implementation complexity without a clear business use
case. This becomes especially complex when the publications exclude
different partitions of the same partitioned table. For example:

pub1: FOR ALL TABLES EXCEPT (part1, part2) WITH
(publish_via_partition_root=true)
pub2: FOR ALL TABLES EXCEPT (part7) WITH
(publish_via_partition_root=false)

IMO, there is no clear need for a user to create multiple 'ALL TABLES'
publications with different EXCEPT lists and then combine them at the
subscriber level. Given this, to keep the patch simpler, we plan to
emit an error for this scenario (multi-pub EXCEPTs case) for now. If a
valid requirement emerges in the future, we can revisit and consider
supporting it.

thanks
Shveta