Re: RFC: logical publication via inheritance root?

On Sat, Jun 17, 2023 at 1:51 AM Jacob Champion <jchampion(at)timescale(dot)com> wrote:
>
> On Fri, Jun 16, 2023 at 6:26 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> > > But if it's because you've implemented a partitioning scheme of your
> > > own (the docs still list reasons you might want to [2], even today),
> > > and all you ever really do is interact with the root table, I think
> > > this feature will give you some of the same benefits that
> > > publish_via_partition_root gives native partition users. We're very
> > > much in that boat, but I don't know how many others are.
> > >
> >
> > I agree that there may still be cases as pointed out by you where
> > people want to use inheritance as a mechanism for partitioning but I
> > feel those would still be in the minority.
>
> (Just to clarify -- timescaledb is one of those cases. They definitely
> still exist.)
>

Noted, but I think that can't be the reason to accept this feature in core.

> > Personally, I am not very
> > excited about this idea.
>
> Yeah, "exciting" isn't how I'd describe this feature either :D But I
> think we're probably locked out of logical replication without the
> ability to override publish_as_relid for our internal tables, somehow.
> And I don't think DDL replication will help, just like it wouldn't
> necessarily help existing publish_via_partition_root use cases,
> because we don't want to force the source table's hierarchy on the
> target table. (A later version of timescaledb may not even use the
> same internal layout.)
>
> Is there an alternative implementation I'm missing, maybe, or a way to
> make this feature more generally applicable? "We have table Y and want
> it to be migrated as part of table X" seems to fall squarely under the
> logical replication umbrella.
>

Are you talking about this w.r.t inheritance/partition hierarchy? I
don't see any other way except "publish_via_partition_root" because we
expect the same schema and relation name on the subscriber to
replicate. You haven't explained why exactly you have such a
requirement of replicating via inheritance root aka why you want
inheritance hierarchy to be different on target db.

The other idea that came across my mind was to provide some schema
mapping kind of feature on subscribers where we could route the tuples
from table X to table Y provided they have the same or compatible
schema. I don't know if this is feasible or how generally it will be
useful and whether any other DB (replication solution) provides such a
feature but I guess something like that would have helped your use
case.

--
With Regards,
Amit Kapila.