On Sun, Aug 15, 2021 at 12:23 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: > > I think the strict separation between publication-for-tables vs. > > publication-for-schemas is a mistake. Why can't I have a publication > > that publishes tables t1, t2, t3, *and* schemas s1, s2, s3. Also note > > that we have a pending patch to add sequences support to logical > > replication. So eventually, a publication will be able to contain a > > bunch of different objects of different kinds. > > This seems like it's going to create a mess, because the meaning of > "include schema S" will change over time as we add more features. > That is, with the present patch (I suppose, haven't read it) we have > "schema S" meaning "publish all tables in schema S". When that other > patch lands, presumably that same publication definition would start > meaning "publish all tables and sequences in schema S". And a few years > down the road it might start meaning something else again. That sounds > like the sort of potentially app-breaking change that we don't like > to make. > > We could avoid that bug-in-waiting if the syntax were more like > "FOR ALL TABLES IN SCHEMA s", which could later extend to > "FOR ALL SEQUENCES IN SCHEMA s", etc. This is then a very clean > intermediate step between publishing one table and "FOR ALL TABLES" > without a schema limitation.
+1 > I tend to agree that a single publication should be able to incorporate > any of these options. I personally prefer that a single publication can include both all tables and all sequences in a database or a schema. It would be a more convenient way to specify replicating all objects (tables and sequences) in a database or a schema. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
