MIME-Version: 1.0
References: <CAAWbhmiRRJDzbA4fv0vAViu_wfoeYqtT+VYOOu7845WO-yT35w@mail.gmail.com>
In-Reply-To: <CAAWbhmiRRJDzbA4fv0vAViu_wfoeYqtT+VYOOu7845WO-yT35w@mail.gmail.com>
From: Jacob Champion <jchampion@timescale.com>
Date: Fri, 6 Jan 2023 13:55:47 -0800
Message-ID: <CAAWbhmiQWEGv73En15WRJ5PmhbwwTdBxMiPxunGghW0G-WVAYg@mail.gmail.com>
Subject: Re: RFC: logical publication via inheritance root?
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAAWbhmiQWEGv73En15WRJ5PmhbwwTdBxMiPxunGghW0G-WVAYg%40mail.gmail.com>
Precedence: bulk

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