On Wed, Aug 26, 2026 at 5:54 PM Dilip Kumar <[email protected]> wrote: > > > Using NULL for local_conflicts in the latter two cases would make the > > column's semantics clearer and the output easier for users to query.
Regarding the fix done for above: insert_conflict_log_tuple: + * In update_missing and delete_missing conflicts, there are no local + * conflicting rows, so set local_conflicts to NULL. */ + if (conflict_type != CT_UPDATE_MISSING && + conflict_type != CT_DELETE_MISSING) + values[attno++] = build_local_conflicts_json_array(conflicttuples); + else + nulls[attno++] = true; I think a better way to handle this would be to have conflicttuples reach here as NULL for these two conflict types, rather than hard-coding the behavior here. If we pass conflicttuples as NULL to ReportApplyConflict() for the these 2 conflicts from apply_handle_update_internal() and apply_handle_delete_internal(), we should be good IMO. ReportApplyConflict() and errdetail_apply_conflict() don't actually use conflicttuples for these two conflict types, so passing it as NULL should work. But I might overlook something, so please give it a try once. thanks Shveta
