RE: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions

On Thursday, December 18, 2025 12:21 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > On Dec 17, 2025, at 16:48, Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com>
> wrote:
> >
> > On Wednesday, December 17, 2025 3:56 PM Chao Li
> <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >> Thank you both for all your advice. Here comes my first
> >> implementation of INHERIT in the attached v2 patch.
> >>
> >> On Wed, Dec 17, 2025 at 8:11 AM Euler Taveira
> <mailto:euler(at)eulerto(dot)com> wrote:
> >>
> >>> I wondering if we use INHERIT as default. The main advantage is
> >>> usability as Chao Li already mentioned. Is there any cases that
> >>> having a different replica identity from parent/partitioned table makes
> sense?
> >>
> >> We can leave this topic open for discussion. In my current
> >> implementation, NO INHERIT is still the default. But if we decide to
> >> switch the default, I can add a new commit that should include only 1
> >> line code change in gram.y and a tiny doc update.
> >>
> >> 0001 - when a new partition is created, use the parent's replication
> >> identity
> >> 0002 - add INHERIT | NO INHERIT
> >
>
> Hi Zhijie,
>
> Thanks for your feedback and linked information. I think this patch is avoiding
> the hard problem of “index” RI.
>
> >
> > I think there are several design considerations for this proposal:
> >
> > 1) Since the index names can vary across different partitions, what
> > should be the expected behavior if a new partition cannot identify the
> > same replica identity key as the root partitioned table?
>
> Index RI is skipped in this patch. INHERT only works for DEFAULT, FULL and
> NONE.
>

I personally find skipping this part to be inconsistent, particularly given the
existing disparities among ALTER TABLE commands related to partitioned table handling.
Omitting this part introduces further inconsistency within the ALTER TABLE
REPLICA IDENTITY.

That said, I understand that skipping this implementation might be necessary due
to technical challenges. It's important, however, to discuss, analyze and document the
specific difficulties associated with implementing this part, and we should
include this information in the code comments and commit message.

Best Regards,
Hou zj