mergedJSONPatch

​

mergedJSONPatch

1. null による削除: パッチ {"key": null} ではキーは削除されません。ColumnObject は挿入時に 値が null のメンバーを破棄するため、この関数は “キーが存在しない” 場合と “キーの値が null である” 場合を区別できません。
2. 空オブジェクトによる置換: パッチ {"a": {}} では、パス a にある古いスカラー値や配列を 置き換えることはできません。ColumnObject は値が空オブジェクト {} のパスを暗黙的に破棄するため、 新しいパッチは何の効果も持たず、古い値がそのまま残ります。
3. 非 Nullable な型付きパスの欠落: JSON カラムで非 Nullable 型の型付きパスを宣言している場合 (例: JSON(a UInt32))、a を省略した行はその型のデフォルト値 (例: 0) で 保存されます。集約関数は “存在しない” 場合と “デフォルト値が明示的に 書き込まれた” 場合を区別できないため、a を省略した新しいパッチによって、古い 0 以外の値が暗黙的に消去されてしまいます。これを避けるには、型付きパスを Nullable として宣言してください (例: JSON(a Nullable(UInt32)))。Nullable な型付きパスの null は “パスが存在しない” ものとして扱われ、正しくスキップされます。
4. 型付きパスはすべてアトミック: すべての型付きパス (Map(K,V)、JSON、Dynamic、Tuple(…)、 Variant(…)、Array(…)、その他宣言された任意の型) は単一の値として保存されます。 集約関数はその内容をディープマージせず、値全体をアトミックに置き換えます。 パス単位でディープマージされるのは、動的な (型指定のないスカラー) パスのみです。
5. キー内のドットによる曖昧さ: JSON 型では、{"a":{"b":1}} と {"a.b":1} がどちらも 同じ内部パス a.b で表現されます。そのため、1 つの行で a と a.b の両方が 独立したピアとして現れることがあります。新しいパッチが a のみを書き込むと、祖先/子孫間の競合 ルールによって a.b が消去され、a.b のみを書き込むと、同じルールによって a が消去されます。これを避けるには、 json_type_escape_dots_in_keys = 1 を設定してください。この設定を有効にすると、JSON キー内のリテラルのドットは パーセントエンコードされ (例: a.b は a%2Eb になります)、ネストされた パスと区別されるため、誤った競合が発生しなくなります。

mergedJSONPatch(json, sort_key)

• json — 集約対象の JSON カラム。JSON
• sort_key — パスごとにどの書き込みを採用するかを決定する、比較可能なカラム。sort_key の値が最大の行が保持されます。

SELECT mergedJSONPatch(json, sort_key) FROM
(
    SELECT '{"a":1}'::JSON AS json, 1 AS sort_key
    UNION ALL
    SELECT '{"b":2}'::JSON, 2
    UNION ALL
    SELECT '{"a":3, "c":4}'::JSON, 3
);

┌─mergedJSONPatch(json, sort_key)─┐
│ {"a":3,"b":2,"c":4}             │
└─────────────────────────────────┘