Re: Skipping schema changes in publication
| От | Andrei Lepikhov |
|---|---|
| Тема | Re: Skipping schema changes in publication |
| Дата | |
| Msg-id | 109c66bc-2871-4fba-8dc1-c57d183e9515@gmail.com обсуждение исходный текст |
| Ответ на | Re: Skipping schema changes in publication (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: Skipping schema changes in publication
|
| Список | pgsql-hackers |
On 6/3/26 11:56, Amit Kapila wrote: > On Fri, Mar 6, 2026 at 1:47 PM vignesh C <vignesh21@gmail.com> wrote: >> > > Instead of a syntax like "ALTER PUBLICATION pub1 DROP EXCEPT TABLE t1" > to allow resetting the entire except list by incrementally dropping > the except tables, I could think of following alternatives IMO, using the 'DROP' syntax is an unusual choice because it does not match how an alter publication process actually happens. > > Option-1: ALTER PUBLICATION pub1 SET ALL TABLES; This suggests it is > still an ALL TABLES publication, but providing a new definition. Since > it didn't include an EXCEPT clause this time, the exception list is > now empty. I vote for a style that allows incremental add/remove table. > If we follow the first one, then we can choose "ALTER PUBLICATION pub1 > SET ALL TABLES EXCEPT TABLE (t1)" to set a new except list instead of > "ALTER PUBLICATION pub1 SET EXCEPT TABLE (t1)" This approach works best for me. It also matches the internal replication logic: take the new publication state, compare it with the old one, and process the differences. -- regards, Andrei Lepikhov, pgEdge
В списке pgsql-hackers по дате отправления: