On Tue, Dec 16, 2025, at 7:12 AM, Amit Kapila wrote:
> On Mon, Dec 15, 2025 at 12:44 PM Chao Li <li.evan.chao@gmail.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
shouldbe 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
simplerthan 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
partitionedtables, where partitions must share the same structure as the parent. In practice, it seems rare for
partitionsto 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/
