> On Dec 17, 2025, at 16:48, Zhijie Hou (Fujitsu) <[email protected]>
> wrote:
>
> On Wednesday, December 17, 2025 3:56 PM Chao Li <[email protected]>
> 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:[email protected]>
>> 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.
>
> 2) Should we simply use the ONLY keyword to determine whether to propagate the
> replica identity to partitions instead of adding [NOT] INHERIT? For example,
> if
> a user specifies ONLY, it changes the identity of the parent table, and any
> newly created partitions will adopt this new identity. However, the identities
> of existing partitions remain unchanged.
The current syntax “ALTER TABLE [ONLY] table_name action”, I think here “ONLY”
works in terms of inherited tables but partitions. (I surprisedly find the doc
doesn’t explain “ONLY” at all.) The current behavior (without my patch) proves
my understanding, “ALTER TABLE table_name REPLICA IDENTITY” only updates the
parent table itself.
Given that it is not allowed to inherit a table from either a partitioned table
(root/parent) or partition (leaf), reusing the “ONLY" at “ALTER TABLE” level
won’t generate a conflict. But the problem is, we will have to revisit all
ALTER TABLE actions to see if they can propagate to partitions when the target
table is a partitioned table. In that case, scope of this patch is extremely
extended.
The current approach adding INHERIT to the action “REPLICA IDENTIFY” has no
global impacts. If you look at the patch, the syntax this patch uses is:
```
ALTER TABLE ...
REPLICA IDENTITY { DEFAULT [ INHERIT | NO INHERIT ] |
USING INDEX index_name |
FULL [ INHERIT | NO INHERIT ] |
NOTHING [ INHERIT | NO INHERIT ] }
```
It explicitly avoids the complexity of “USING INDEX”, thus we don’t have to
mention any exceptions in docs.
Amit, what do you think?
>
> 3) There have been previous discussions on similar proposals[1][2]. It might
> be
> beneficial to review those debates to see whether any old issues or arguments
> are pertinent to this proposal.
>
> [1]
> https://www.postgresql.org/message-id/flat/201902041630.gpadougzab7v%40alvherre.pgsql
> [2]
> https://www.postgresql.org/message-id/flat/OSBPR01MB2982A2738F16722899A50082FECB0%40OSBPR01MB2982.jpnprd01.prod.outlook.com#2e5388a7cde3c10430f8668a6c381b06
>
I read through the both threads. I think the key difference between the patch
and the previous one is that this patch only adds “INHERIT” to
DEFAULT/FULL/NONE, which is narrow scoped. Let’s see how the folks who involved
in the previous discussion will feedback to this patch.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
