Postgres の生成カラム: 注意点とベストプラクティス

レプリケーション対象のテーブルで PostgreSQL の生成カラムを使用する場合は、いくつかの重要な注意点があります。これらは、レプリケーション処理や宛先システムでのデータ整合性に影響を及ぼす可能性があります。

生成カラムの問題

pgoutput 経由では公開されない: 生成カラムは、pgoutput 論理レプリケーションプラグイン経由では公開されません。つまり、PostgreSQL から別のシステムへデータをレプリケートする場合、生成カラムの値はレプリケーションストリームに含まれません。
主キーに関する問題: 生成カラムが主キーの一部になっている場合、宛先で重複排除の問題を引き起こす可能性があります。生成カラムの値はレプリケートされないため、宛先システムは行を正しく識別して重複排除するために必要な情報を持てません。
スキーマ変更に関する問題: すでにレプリケーション対象のテーブルに生成カラムを追加しても、その新しいカラムは宛先では populated されません。これは、Postgres がその新しいカラムに対する RelationMessage を返さないためです。さらに、その同じテーブルに新しい非生成カラムを追加すると、ClickPipe はスキーマをリコンサイルしようとした際に、宛先内で生成カラムを見つけられず、結果としてレプリケーション処理が失敗します。

これらの制約を回避するため、次のベストプラクティスを検討してください。

宛先で生成カラムを再作成する: 生成カラムの処理をレプリケーションに任せるのではなく、dbt (data build tool) やその他のデータ変換の仕組みを使って、宛先側でこれらのカラムを再作成することを推奨します。
主キーで生成カラムを使用しない: レプリケーション対象のテーブルを設計する際は、生成カラムを主キーの一部に含めないようにするのが最善です。

今後のバージョンでは、次のことを支援する UI を追加する予定です。

生成カラムを含むテーブルの特定: UI には、生成カラムを含むテーブルを特定する機能が追加されます。これにより、この問題の影響を受けるテーブルを把握できます。
ドキュメントとベストプラクティス: UI には、レプリケーション対象テーブルで生成カラムを使用する際のベストプラクティスが含まれ、よくある落とし穴を避ける方法についてのガイダンスも提供されます。