動的SQLを実行する関数があります(SQLインジェクション、「ボビーテーブル」攻撃ですが、それは別の問題です)。 2つのパラメーターを取り、最初のパラメーターを2番目のパラメーターに補間し、ブール値を返します。
このように実行すると:
SELECT util.dynsql('M','SELECT EXISTS (SELECT 1 FROM x WHERE y = INPUT_VALUE)');
その後、正常に動作します。 'M'をINPUT_VALUEがある場所に置き、それをテーブルxで見つけて、trueを返します。
このように実行すると:
SELECT util.dynsql('M','SELECT EXISTS (SELECT 1 FROM x WHERE y = INPUT_VALUE)')
FROM some_table limit 1;
その後、falseを返します。 some_tableは任意のテーブルにすることができます。つまり、FROMがある場合、それは機能しません。
なぜ何か提案はありますか?いいえ、申し訳ありませんが、dynsql関数のコードを投稿できません。
2番目のパラメーターにSELECTが含まれていない場合、それが比較または正規表現である場合は、機能します。動的SQLのSELECTは、テーブルからのクエリでは機能しないようですが、テーブルからではないクエリでは機能します。
これは、PostgreSQL 8.4で導入されたパラメーター化された動的SQLを持たないGreenplumにあり、GreenplumはPostgres8.2に基づいて構築されています。
行が含まれているセグメント*で関数が実行されており、セグメントがより広いデータベースにアクセスできないため、選択できないため、失敗しています。
*セグメントは、サーバーのクラスター内の単一サーバーのように、分散データベース内のノードです。データは複数のサーバーに分散されており、テーブルから選択すると、単一のサーバーが機能を実行しますが、そのサーバーは他のサーバーにアクセスできません。