PostgreSQL範囲型のカンマ含む境界パーサを修正

PostgreSQL::OID::Range#extract_bounds がカンマを単純分割したため、クォートされた境界にカンマが含まれると範囲が破損していました。テキスト系サブタイプや money 型で顕在化し、読み出し時にデータが消失する高リスクのバグです。本修正はクォートを認識した分割ロジックを導入し、正しい境界復元と安全なフォールバックを提供します。

背景

PostgreSQL::OID::Range#extract_bounds は範囲文字列を value[1..-2].split(",", 2) で分割していましたが、PostgreSQL はカンマを含む境界を二重引用符でエスケープします。その結果、["a,b","c,d") のような表現が "a と b","c に分割され、下限・上限の両方が破損しました。テキスト・varchar・money など、境界にカンマが入るサブタイプでのみ影響し、数値系 (int4range、numrange、tsrange、daterange) は安全でした。特に money は金額が千単位でカンマを含むため、範囲全体が 0.0..0.0 に変換される沈黙のデータロスが発生しました。

技術的な変更

extract_bounds は split_bounds ヘルパーへ置き換えられ、クォートを考慮した正規表現 BOUNDS が新たに導入されました。split_bounds はまず value.include?("\"") でクォート有無を判定し、無ければ従来の split(",", 2) を高速に使用します。クォートがある場合は BOUNDS (/\A((?:"(?:[^"\\]|""|\\.)*"|[^,"])*),(.*)\z/m) で下限と上限を安全に抽出し、マッチしない場合は [value, nil] を返すフォールバックを提供します。

@@
-            from, to = value[1..-2].split(",", 2)
+            from, to = split_bounds(value[1..-2])
@@
-            if value.start_with?("\"") && value.end_with?("\"")
+            if value && value.start_with?("\"") && value.end_with?("\"")

BOUNDS のコメントは、クォート内部の " と \\ エスケープをスキップしつつ最初のカンマを捕捉する意図を説明しています。/m フラグにより改行を含む上限も正しく取得でき、正規表現の実行はカンマを含む稀なケースだけに限定されます。ベンチマーク結果は、組み込み型でのオーバーヘッドが約1.2倍に抑えられ、クォート付きケースでも実用的な速度を維持しています。

テストスイートにも 6 件の新規テスト が追加され、カンマ付き境界、エスケープされた引用符・バックスラッシュ、部分的クォート、開放境界、改行入り境界、空文字境界を網羅的に検証しています。すべてのテストは main ブランチで失敗し、修正後は緑となり、実際の PostgreSQL インスタンスでも正しく読み戻せることが確認されています。

設計判断

修正は 既存インターフェースを保持 しつつ内部ロジックだけを拡張する方針で実装されました。split_bounds が高速パスを提供することで、ほとんどの組み込み範囲型に対するパフォーマンス影響を最小化し、カスタムテキスト系範囲だけが正規表現にフォールバックします。この選択は 後方互換性 と 実装コスト のトレードオフを考慮し、既存コードの変更箇所を extract_bounds の1行と unquote の安全チェックに限定しています。また、unquote が nil を受け取った際に例外を出さずそのまま返すようにしたことで、 malformed 入力に対しても安全にデグレードする設計となっています。

まとめ

本PRは PostgreSQL の範囲型でカンマを含むクォート境界が破損する問題を、クォート認識正規表現と高速フォールバック によって根本的に解消しました。既存 API の互換性は維持しつつ、実装は最小限の変更に留められ、広範なテストで信頼性が裏付けられています。これによりテキスト系や money 型の範囲データが正確に復元され、データロスのリスクが除去されました。