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

When using PostgreSQLの生成されたカラムをレプリケートされているテーブルで使用する場合、いくつかの重要な考慮事項があります。これらの問題は、レプリケーションプロセスおよび宛先システムにおけるデータの整合性に影響を及ぼす可能性があります。

生成されたカラムの問題

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

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

宛先で生成されたカラムを再作成する: レプリケーションプロセスに生成されたカラムの処理を頼るのではなく、dbt（data build tool）や他のデータ変換メカニズムを使用して、宛先でこれらのカラムを再作成することをお勧めします。
主キーに生成されたカラムを使用しない: レプリケートされるテーブルを設計する際には、生成されたカラムを主キーの一部として含めることは避けるべきです。

今後のバージョンでは、ユーザーが次のことを手助けするUIを追加する予定です。

生成されたカラムを含むテーブルの識別: UIには、生成されたカラムを含むテーブルを識別する機能が追加されます。これにより、ユーザーはこの問題の影響を受けるテーブルを理解するのに役立ちます。
ドキュメンテーションとベストプラクティス: UIには、レプリケートされたテーブルで生成されたカラムを使用するためのベストプラクティスが含まれ、一般的な落とし穴を避けるためのガイダンスが提供されます。