Re: pg_get_publication_tables() output duplicate relid

On Thu, Dec 2, 2021 at 9:44 houzj(dot)fnst(at)fujitsu(dot)com
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> On Wed, Dec 1, 2021 3:01 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > On Mon, Nov 22, 2021 at 12:55 PM Amit Langote
> > > > <amitlangote09(at)gmail(dot)com> wrote:
> > > > > On second thought, I agree that de-duplicating partitions from
> > > > > this view is an improvement.
> > > >
> > > > Fair enough. Hou-San, Can you please submit the updated patch after
> > > > fixing any pending comments including the test case?
> > >
> > > Attach the updated patch which address the comments so far.
> > >
> > > The patch only adds a testcase in publication.sql because the
> > > duplicate output doesn't cause unexpected behavior in pub-sub test.
> >
> > Thanks, the patch looks good to me. I have slightly changed the commit
> > message in the attached. I would like to commit this only in HEAD as there is no
> > user complaint about this and it might not stop any user's service unless it relies
> > on this view's output for the initial table synchronization.

The patch looks good to me too in that it gets the job done.

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. Sorry about too many second thoughts on these
threads. :(

> > What do you think?
> I agreed that we can commit only in HEAD.

+1 to do this only in HEAD.

Thank you.

--
Amit Langote
EDB: http://www.enterprisedb.com