このかなり単純なpostgresql 9.6関数が
CREATE OR REPLACE FUNCTION public.trying_to_index_me()
RETURNS VOID AS
$BODY$
BEGIN
CREATE TABLE public.table_to_index (
id INTEGER NOT NULL,
this_id UUID NOT NULL,
that_id smallint NOT NULL,
CONSTRAINT idx_table_to_index_unique
UNIQUE (id,this_id,that_id)
);
CREATE INDEX idx_table_to_index_thisthat ON public.table_to_index(this_id,that_id);
DROP TABLE public.table_to_index;
END;
$BODY$ LANGUAGE plpgsql;
--SELECT public.trying_to_index_me();
になりschema "" does not exist error
ます。正確なエラーは次のとおりです。
ERROR: schema "" does not exist
SQL state: 3F000
Context: SQL statement "CREATE INDEX idx_table_to_index_thisthat
ON public.table_to_index(this_id,that_id)"
PL/pgSQL function trying_to_index_me() line 10 at SQL statement
2回目以降の実行で確実に発生します。上記の SQL チャンクを切り取って貼り付けると、エラーが再現されます...私にとっては。それがあなたに当てはまらない場合は、非常に興味があります。次の手がかりがあります。
- エラー メッセージで検出されたスキーマはさまざまです。ほとんどの場合、"" として報告されますが、"0MA{Start of Text} " や、トランザクション内の前のステートメントからの SQL ステートメント/コメントの一部のスニペットなども報告されます。メモリポインタ関連の音。
- いったん入ると、一貫してエラーが発生します。
- 関数を CREATE OR REPLACE すると、1 回実行された後、エラー状態が再び発生することがわかりました。
- 新しい pgadminIII ウィンドウを開くと (ドロップまたは再作成せずに)、同じ実行が行われ、別のウィンドウでエラーが発生したかどうかに関係なく、エラー状態が再び発生することがわかりました。接続関連の音。
idx_temp_data_to_index_thisthat
orの作成をコメントアウトするとidx_temp_data_to_index_unique
、問題が解決することがわかりました。- 「x86_64-pc-linux-gnu 上の PostgreSQL 9.5.3、gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)、64 ビットでコンパイル」と 9.6 実装の両方で発生します。
- 上記の関数が別の関数から実行される場合、上記の CREATE OR REPLACE FUNCTION の 1 回限りの解決は親関数では機能せず、子関数を置換する場合にのみ機能します。それが別の pgadmin ウィンドウで発生するかどうかは問題ではありません。Pクライアントでもトランザクションでもないように聞こえます。
あなたの考えを本当に感謝します。