On Tue, Dec 16, 2025, at 7:12 AM, Amit Kapila wrote:
> On Mon, Dec 15, 2025 at 12:44 PM Chao Li <[email protected]> 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/

Attachment: ri.sql
Description: application/sql

Reply via email to