Re: Skipping schema changes in publication

On Mon, Mar 23, 2026 at 12:35 PM shveta malik <shveta.malik@gmail.com> wrote:
>
> I would like to summarize the discussion/feedback for the EXCEPT
> syntax implemented in [1].
>
> 1)
> The currently implemented syntax is ([1]):
>
> CREATE PUBLICATION pub FOR ALL TABLES EXCEPT TABLE (a, b, c);
>
> There were concerns about why the TABLE keyword and the parentheses
> '()' are required. These have been answered in [2].
>
> Please review the discussion there.
>
> 2)
> Another feedback on current syntax was to move the TABLE keyword
> inside the parentheses:
>
> CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, TABLE t2,
> TABLES IN SCHEMA s1);
> CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1 EXCEPT (TABLE t1, TABLE
> t2), TABLE t3;
>
> While this approach is workable, a downside is the repeated use of the
> TABLE keyword inside the parentheses, which can become verbose. But it
> can then be optimized to have:
>
> CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, t2, t3);
>
> This could be extended further in the future:
>
> CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE t1, t2, TABLES IN
> SCHEMA s1, s2);
>
> This approach gives users flexibility to mix styles, for example:
>
> EXCEPT (TABLE t1, TABLE t2, TABLE t3)
> EXCEPT (TABLE t1, t2, t3)
> EXCEPT (TABLE t1, t2, TABLE t3)
> EXCEPT (TABLE t1, TABLES IN SCHEMA s1, s2, TABLE t2, t3)
>
> While flexible, this can reduce clarity due to mixed styles, making
> the statement harder to read. If extended further, the syntax could
> evolve into something like:
>
> CREATE PUBLICATION pub1 FOR
> ALL TABLES
>    EXCEPT (TABLE t1, t2, TABLES IN SCHEMA s1, s2),
> ALL SEQUENCES
>    EXCEPT (SEQUENCE s1);
>
> At this point, one might also question why not allow something like:
> FOR ALL (TABLES, SEQUENCES).
>
> Additionally, this shows a potential drift toward less structured
> syntax. Instead, with the syntax already implemented in [1], its
> future extension would look like:
>
> CREATE PUBLICATION pub1 FOR
> ALL TABLES
>    EXCEPT TABLE (t1, t2),
>    EXCEPT TABLES IN SCHEMA (s1, s2),
> ALL SEQUENCES
>    EXCEPT SEQUENCE (seq1, seq2);
>
> Although slightly more verbose, this approach keeps each clause
> self-contained and explicit. The meaning of each part is determined
> locally, rather than depending on elements appearing far in the
> statement.
>
> The current syntax in [1] is simple and easy to follow. We have
> retained the current implementation for now, while remaining open to
> further discussion and suggestions.
>
> [1]:
> https://www.postgresql.org/message-id/CALDaNm2-Ob9qPR%2BvqUSVMkxYO8RW4LQ_S1XiB0Y7xa54U%3DDqbA%40mail.gmail.com
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fd366065e06ae953c4f2d973d5c5f0474f3b87b6
>
> [2]: https://www.postgresql.org/message-id/CAJpy0uB20MhJJEaPJdm31t4fykJ%2BfChA_76jU2P9HX5knbJvAA%40mail.gmail.com


Thanks for the summary. While I find the current implementation
simpler and more intuitive, and would prefer it if we were designing
this from scratch, we must consider the existing patterns for table
inclusion. Since the inclusion syntax already supports a mixed
approach, users will likely expect the same flexibility for
exclusions. For the sake of consistency across the features, I believe
we should move toward the mixed approach, despite my preference for
the current structured style.  Of course, this is just my opinion, and
others' mileage may vary.

-- 
Regards,
Dilip Kumar
Google