Re: pg_get_publication_tables() output duplicate relid

On Mon, Dec 6, 2021 at 3:55 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
> On Thursday, December 2, 2021 9:48 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > 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.
>
> After thinking more on this. I find there might be some usage about adding both
> child and parent to the publication.
>
> For the future feature publication row filter(and maybe column filter), It
> could be useful for user to adding child and parent with different filter
> expression. If pubviaroot=true, user can expect the parent's filter take
> effect, If pubviaroot=false, they can expect the child's filter take effect.
>
> If we disallow adding both child and parent to publication, it could be harder
> for these features to implement.

It's possible that one may want such a feature, and yes, outright
preventing adding both the parent and a partition to a publication
would perhaps make it harder.  Mind you though that any such feature
would need to fix the current implementation anyway to make the
publication-behavior-related catalog entries for child tables, which
we currently don't, unless children are added explicitly.

That said, we should also be careful in implementing new features that
offer a finer per-partition granularity, because the fact that we do
currently offer that for many of the existing old features such as
constraints, indexes, etc. limits the scalability of our architecture.
That point may be off-topic for the thread, but something to consider,
or maybe I need to take a look at the other patch to see if my
concerns are addressable / have been addressed.


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