pg_prepared_statements

авторstatement text The query string submitted by the client to create this prepared statement. For prepared statements created via SQL, this is the PREPARE statement submitted by the client. For prepared statements created via the frontend/backend protocol, this is the text of the prepared statement itself.

на самом деле там будет валяться ВЕСЬ стейтмент . если это батч -- будет весь батч. [т.е. current_query()]



что, впрочем, не мешает выполняться по вызову только самому стейтменту.

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

надо будет нарезать сами стейтменты на loop-е. "отдельными стейтментами", т.с.

а англичане, меж тем, ружья кирпичом не чистятЪ1111

qwwq<>надо будет нарезать сами стейтменты на loop-е. "отдельными стейтментами", т.с.
ашипка вышел -- это же один SQL--динамо. исполняемый пачкой. как в нем отдельно стоящий loop нарисовать -- х.з.

не выходит каменный цветок.
придется таки с клиента все это делать. а не на сервере. если делать.
вот жишь до чего довёл планету этот фигляр пж

Warstoneqwwq,

dblink к самому себе с шарингом транзакции ))

можно, но там мыслился аккуратный выборочный DEALLOCATE , у которого нет "IF EXISTS" , а стало быть только через динамику в анонимном блоке. -- т.е. "пакет" должен будет представлять собой анонимный блок с вызовом через dblink чеков тамошнего набора стейтментов, с [уничтожением и ] созданием каждого отдельным стейтментом, а потом -- пересылку батча в то же соединение 100--тыщщ--мильонов символов в dblink. т.е. 2 раза передаем весь пакет -- в вызов, собственно, и в дблинк -- потом. А это -- дорого, думается.

при этом, если мы подымаем соединение автономии под задачу -- делать в нём "аккуратный deallocate" -- бесмыссленно -- это соединение наше заведомо под контролируемую только нами задачу -- там можно и не церемониться

пока сделал тупо deallocate all; в батче.
//пг_препаред_ст-тс -- вьюха, и каррент стейтмент там не хранится, слава яйцам, а вот опрос её -- дорог, потому что это вьюха на функции, и функция будет возвращать миллионы символов в поле, которое не опрашивается. -- избавляемся от опроса => нема проблем

вроде шустро получилось -- порядок (десятичный), как минимум, сэкономил. правда там не чистые insert/update/delete, а самопальные мерджи со сложным условием [помесь репликации с синхронизацией]. особо радует -- что на очень большом батче без препаред сервер тупо уходит в recovery [настройки памяти оптимистические, судя по всему] -- а с препарами -- оттарабахивает за несколько сек, и не жужжит.

но самое смешное -- всё это [пока] для того, чтобы проверить, как это будет работать в случае динамического партицирования. (когда набор партиций, лежащих под "таблицей" меняется в процессе обработки стейтментов батча--транзакции, а стейтменты отпрепарены только в её начале.

-- написать -- написал, теперь думать буду, как это протестировать на непротиворечивость и устойчивость к "динамическому" партицированию.

Maxim Boguk> самые простые и дубовые решения лучше всего<

двумя руками за