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 по дате отправления: