Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions

On Tue, Dec 16, 2025, at 7:12 AM, Amit Kapila wrote:
> On Mon, Dec 15, 2025 at 12:44 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>>
>> From this perspective, when a new partition is created, it should automatically inherit the parent’s RI. With that behavior, a “FORCE” option would rarely be needed, because having one partition use a different RI from its siblings should be an uncommon case.
>>
>> Based on this, I imagine the feature roughly like this:
>>
>> * When a new partition is created, it inherits its parent’s RI
>> * ALTER TABLE <table_name> REPLICA IDENTITY [ INHERIT | NO INHERIT ] -- error out on conflicts
>>
>
> Sounds reasonable to me.
>

+1.

>> This leads to a couple of follow-up questions:
>>
>> * Should RI be switchable between “inheritable” and “non-inheritable”, similar to constraints? IMO, no. RI is much simpler than constraints. For constraints, parent–child relationships exist between tables with potentially different structures, so it is natural that child tables might have different constraints. RI, however, only applies to partitioned tables, where partitions must share the same structure as the parent. In practice, it seems rare for partitions to intentionally use a different RI than the parent.
>>
>
> I see your point but I think we should provide resetting the option
> unless it is too complex or not feasible.
>

+1.

ALTER TABLE ...
REPLICA IDENTITY { DEFAULT [ INHERIT | NO INHERIT ] |
USING INDEX index_name |
FULL [ INHERIT | NO INHERIT ] |
NOTHING [ INHERIT | NO INHERIT ] }

It doesn't make sense to have the inheritance property for INDEX. Although the
natural default value is NO INHERIT to preserve backward compatibility, 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?

--
Euler Taveira
EDB https://www.enterprisedb.com/