Re: Skipping schema changes in publication

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
Shveta