Re: RFC: logical publication via inheritance root? - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: RFC: logical publication via inheritance root?
Date
Msg-id CAAWbhmiQWEGv73En15WRJ5PmhbwwTdBxMiPxunGghW0G-WVAYg@mail.gmail.com
Whole thread Raw
In response to RFC: logical publication via inheritance root?  (Jacob Champion <jchampion@timescale.com>)
Responses Re: RFC: logical publication via inheritance root?  (Aleksander Alekseev <aleksander@timescale.com>)
List pgsql-hackers
On Fri, Dec 9, 2022 at 10:21 AM Jacob Champion <jchampion@timescale.com> wrote:
> Some inheritance hierarchies won't be "partitioned" hierarchies, of
> course, but the user can simply not set that replication option for
> those publications.

The more I noodle around with this approach, the less I like it: it
feels overly brittle, we have to deal with multiple inheritance
somehow, and there seem to be many code paths that need to be
partially duplicated. And my suggestion that the user could just opt
out of problematic cases would be a bad user experience, since any
non-partition inheritance hierarchies would just silently break.

Instead...

> (Alternatively, I can imagine a system where an
> extension explicitly marks a table as having a different "publication
> root", and then handling that marker with the existing replication
> option. But that may be overengineering things.)

...I'm going to try this approach next, since it's opt-in and may be
able to better use the existing code paths.

--Jacob



pgsql-hackers by date:

Previous
From: Arne Roland
Date:
Subject: Permute underscore separated components of columns before fuzzy matching
Next
From: Bruce Momjian
Date:
Subject: Re: GROUP BY ALL