Re: Skipping schema changes in publication
| От | Shlok Kyal |
|---|---|
| Тема | Re: Skipping schema changes in publication |
| Дата | |
| Msg-id | CANhcyEXp_AH-oms=psQ3jkMdvd9kp57d-6f7=8yuz_EX0VTa7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Skipping schema changes in publication (Peter Smith <smithpb2250@gmail.com>) |
| Список | pgsql-hackers |
On Thu, 11 Dec 2025 at 04:31, Peter Smith <smithpb2250@gmail.com> wrote: > > On Wed, Dec 10, 2025 at 4:49 AM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote: > > > > On Mon, 24 Nov 2025 at 13:03, Peter Smith <smithpb2250@gmail.com> wrote: > > > > ... > > > 21. > > > I was wondering if the "describe" for tables (e.g. \d+) should also > > > show the publications where the table is an ECEPT TABLE? How else is > > > the user going to know it has been excluded by some publication? > > > > > I thought it would be sufficient to show only the list of > > publications, the table is part of. > > Users can check the excluded tables by checking the description of the > > publication using \dRp+. > > Will it be not sufficient? > > I am not sure why we should show a list of publications which it is not part of? > > Am I missing something thoughts? > > For this comment, I was imagining a scenario where there are dozens of > publications, and the user is wondering why their table is not being > replicated to the subscriber like they expected it would be. > > Yes, they could use \dRs+ to identify the publications excluding it, > but that will be quite painful if there are very many publications > they have to check. IIUC, there is no other way to check it without > digging into System Catalogs. > > That's why I thought it might be useful if the \d+ could also show > publications where the table was named in an EXCEPT TABLE clause. > I thought more about this point and it can be useful. I have added the changes for the same in the latest patch in [1]. [1]: https://www.postgresql.org/message-id/CANhcyEWg2WbEW_fFwk0D3J2KBrUF7th6VrE%2BgvESgkUKP9VpZg%40mail.gmail.com Thanks, Shlok Kyal
В списке pgsql-hackers по дате отправления: