私は頻繁にpg_dumpを使ってデータベースをダンプし、それらをdiffと比較します。ほとんどの「誤検出」を取り除くために、pg_dumpを修正して、テーブルをソートして、ダンプされた順序が必要以上に変更されないようにしたいと考えています。一意性でソート可能なテーブルの属性のリストを取得する
私はクエリを探していますソート可能な（例えば、XMLフィールドがない）テーブルの属性のリストを返し、 "一意性"によってソートされます。 e。プライマリキーを表す第1の属性、次に他のユニークなキー、そして残りのキー。
私はPostgreSQLのシステムカタログの深みに着く前に、誰もこの問題を既に解決していますか？
あなたは次のようにクエリの束を書くことができます：
COPY (SELECT * FROM T ORDER BY ...) INTO t.csv
とcsvファイルに各テーブルの結果セットを記述します。セットオーダーで書かれているので、簡単に比較できるはずです。
これはpg_dumpをハッキングするよりはるかに簡単です。
あなたが標準INFORMATION_SCHEMAを使用して取得することができ、テーブルのすべての列：
select * from information_schema.columns;
私は両方を知っていますが、pg_dumpをハッキングするのはそれほど難しくありません。すべての列のリストには興味がありませんが、一意性でソート可能な列は興味がありません。 –
正しい質問を書いてください。私は本当にそれがあなたが既存の問題を解決したい理由を取得していない。他方では、いつでも両方のダンプをデータベースにロードすることができます（400MBは本当に小さなデータベースです）、単純なクエリの束を使って比較します。 –
ええと、この質問の目的は正しい質問を見つけることです。そして、私が（またはgitまたはrdiff-backupまたは...）2つのダンプを比較したい場合、それらをデータベースにロードすることは、pg_dumpを調整するよりはるかに多くの作業（実行可能であっても）です。とにかくありがとう。 –
も...これらのデータベースをどのように大きなですか？ –
@SzymonGuz私のプライベートデータベースの典型的なダンプは400MByteです。それはなぜ重要なのでしょうか？ –
おそらく、各テーブルをソートすると、ダンプが長くなり、より多くのメモリが消費されるため、現時点ではそれが行われません。 – araqnid