Re: pg_get_publication_tables() output duplicate relid
От | Amit Langote |
---|---|
Тема | Re: pg_get_publication_tables() output duplicate relid |
Дата | |
Msg-id | CA+HiwqGeYc2ij-t8Gv7SJ+YLAU59EqAqRyvUTgi2qb268v4oJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_get_publication_tables() output duplicate relid (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pg_get_publication_tables() output duplicate relid
RE: pg_get_publication_tables() output duplicate relid |
Список | pgsql-hackers |
On Thu, Dec 2, 2021 at 2:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > On Thu, Dec 2, 2021 at 8:42 AM Amit Langote <amitlangote09@gmail.com> wrote: > > Reading Alvaro's email at the top again gave me a pause to reconsider > > what I had said in reply. It might indeed have been nice if the > > publication DDL itself had prevented the cases where a partition and > > its ancestor are added to a publication, though as Hou-san mentioned, > > partition ATTACHes make that a bit tricky to enforce at all times, > > though of course not impossible. Maybe it's okay to just de-duplicate > > pg_publication_tables output as the patch does, even though it may > > appear to be a band-aid solution if we one considers Alvaro's point > > about consistency. > > True, I think even if we consider that idea it will be a much bigger > change, and also as it will be a behavioral change so we might want to > keep it just for HEAD and some of these fixes need to be backpatched. > Having said that, if you or someone want to pursue that idea and come > up with a better solution than what we have currently it is certainly > welcome. Okay, I did write a PoC patch this morning after sending out my earlier email. I polished it a bit, which is attached. -- Amit Langote EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: