Re: Replace is_publishable_class() with relispublishable column in pg_class
| От | Andres Freund |
|---|---|
| Тема | Re: Replace is_publishable_class() with relispublishable column in pg_class |
| Дата | |
| Msg-id | fpepoh22dwjlnhn6v7f5ksicxqmtxy6scvfqkjrrcdjytmn2hk@chy5pcp26ln4 обсуждение исходный текст |
| Ответ на | Re: Replace is_publishable_class() with relispublishable column in pg_class (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Replace is_publishable_class() with relispublishable column in pg_class
|
| Список | pgsql-hackers |
Hi, On 2025-12-16 11:28:11 -0500, Andres Freund wrote: > On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote: > > 2) As suggested by Amit Kpila [2], for the upcoming Conflict Log Table > > feature, we need a clean way to exclude these internal conflict log > > tables from publication. A catalog flag allows us to set this property > > at relation creation rather than adding more special cases. > > Seems like the issue here also could be addressed the same way? Actually, wouldn't a table-level property be completely inappropriate for that? Imagine one publication that's used for HA (or major version upgrade) and doesn't use a conflict table, which replicates all tables (including the conflict table of another pub/sub). And a subscription doing bi-direction replication that *does* obviously use the conflict table. In one of those cases you want to replicate changes to the conflict table, in the other not. So a table / pg_class property would be inappropriate, no? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: