bsa1959,

вы путаете SQL-execute с plpgsql-execute-ом
а это разные языки.

как делать SQL-execute - внутри plpgsql недавно тут было.
а именно через plpgsql-execute

примерная идея:



хотя, сама идея использования sql-prepare/execute внутри plpgsql - спорна.

qwwq,

с USING вышел обломайзинг.

но вот так:

qwwq<....>

хотя, сама идея использования sql-prepare/execute внутри plpgsql - спорна.
забавно, но , кажется, нашёлся случай, когда это имеет смысл
а именно:
в хранимке делаем гробовый динамич. скл.
и в цикле по выборке из него надо сделать проверки (тысячи их), которые проще всего выглядят как (почти такой же, как отбирающий курсор LOOP-а) динамические скл (второй вариант - глобальный if elsif со статическими (вариантами) проверками повторяющий структуру пошива динамики sql, у котором надо, по сути, повторять ту же логику, что и при сборки динамики). т.к. в цикле парсить и планировать один и тот же параметрический запрос, только подставляя новые параметры - накладно, то препарнуть на входе собранный скл, и подставлять в цикле парамсы - самое оно.
(хотел найти исходный пост с таким хаком - поблагодарить автора -- не нашёл)

т.ч. резюме: using бы тут не помешал.

попался второй случай:

Maxim Boguk <>
все sql запросы (кроме execute) в pl/pgsql коде препарятся при первом вызове функии и дальше работают уже prepared
(Т.е. pl/pgsql автоматически делает то что вы хотите).

<>
-- на входе таблица смеси метаданных [tablename] с данными [этих tablename], по каждой записи которой строится динамический запрос.

обрабатываем батч (запрос) в 4000 строк этой таблички, с полем, построенным по метадата+дата упомянутым динамическим запрсом.

как правило большое число повторений (т.е. внутри можно было бы реализовать некое количество стетйментов foo_{tableoid}(record), и их дёргать .

тесты дают (если метаданные выродить, т.ч. только один prepared) --
строчная ф-я:
1. каждый раз разбирать динамику -- 8.5сек.
2. запихать как выше в prepare (EXCEPTION WHEN OTHERS -- deallocate all; PREPARE foo(record)....) 2.5 сек
т.е. разобрать единожды, 4000 раз выполнить -- дешевле
2.1 запихать как выше в prepare (EXCEPTION WHEN OTHERS -- deallocate all; PREPARE foo(bigint)....) 0.37 сек (record -- это общий случай метадата -- ROW({p_key_filds})=ROW({p-key_value}) ; bigint -- частный случай тестов)



но, прямая подстановка (все 4000 записей ссылаются на 1 метаданное(таблицу) и данные в ней:
3. Прямой запрос [не через ф-ю, а прямая подстановка корелята в ] 170ms.

можно конечно двигаться в сторону 3 -- прямой пошив итогового union all по всем случаям метадата [+sort]. но 2.1. несколько проще кажется в реализайции (синтаксически проще 2, и оно по индексу таки планирует, если запускать в тестах такую конструкцию руками, даже с перестановкой полей в сложносоставных индексах, но почему такая просадка -- не ясно. но т.к. в EXECUTE 'EXECUTE ' (как и в EXECUTE 'COPY ' параметры не просачиваются через USING [этот SQL SQL-нее прочего]),а я record не умею через текст передавать [без потери инфы о типах], а в передаче типов через row() -- изюмина 1. [и отличия 2. от 2.1] -- то видимо за 2.1. имеет смысл побороться)


* изящным выходом могла бы быть "TEMPORARY FUNCTION", если б была. Тогда бы вернулись к цитате из максима.
** тесты на вырожденноом случае -- в data лежат NULL, иначе времена были бы ближе

PS: вопросы (в т.ч. риторические):
а. -- почему в SQL--command 'COPY' и 'EXECUTE' нельзя передать параметр через plpgsql EXECUTE ... USING ? саботаж, имхо :o]
б. -- почему просаживается при PREPARE FOO(record) ? как это выяснить?

Maxim Boguk <>
90% что время уходит на сериализацию record в текст и назад (это не особо дешевая процедура).

похоже на то. -- реализовал п.2. не через WHERE row()=row(), а через явный текст WHERE key1=val1 [AND key2=val2[ AND...]]

получил "Total runtime: 5867.584 ms" -- 3 сек. разницы на том же батче из 4000 записей. Думаю, на prepared тоже что-то сносное получу. И запись через текст передавать не надо будет.
Так-то все представления дата.value у меня текстовые (точнее hstore). я их в row силком вгонял. уже с типами.

реализовал черновик 2+ prepare без ROW и обратно
черновик -- т.к. нет уникальных foo-i, а для одной конкретной метадата:

"Total runtime: 638.307 ms"

-- теперь думать буду -- а нужна мне такая кухня создания кучки foo-i внутри одного батчевого стейтмента.
или скромнее надо быть