Sasha AliasА кому это нужно?

На самом деле есть идей и с развитием plproxy, например:
- добавить поддержку INSERT, UPDATE, DELETE.
- добавить поддержку анонимных plproxy блоков для DO (для чего DO должно научиться возвращать результаты)

В результате можно получить чрезвычайно мощный map/reduce фреймворк на базе SQL.
если обработки нет - нужна обёртка (на языке, где обработка есть)

если обертка будет в пж (plpgsql) -- весь объём параметров (весь поток данных) придется присваивать 2-ды -- по значению
один раз при запросе обёртки
второй - при вызове из обёртки плпрокси-хранимки

или исхитрятся
например на клиенте

Misha Tyurinйццй,

авторхочу делать это на проксирующем узле (в обработчике).
http://plproxy.projects.pgfoundry.org/doc/todo.html
Good to have
* RUN ON ANY: if one con failed, try another

что-то типа того планировали планировали, да и забилину это я сразу заметил да,

так же как RUN ON ALL:ignore errors
-- руками это, последнее, делается тоже через plpgsql обертку, и RUN ON _node; в цикле по нодам с обработчиком. можно даже асинхронность прикрутить. типа для параллельности, если невтерпёж.
Проблема та же - двойное присвоение параметров - один раз передача в обертку , второй - в plproxy из обертки
но обычно RUN ON ALL это вызовы выборок [ну и ddl так удобно разливать при апгрейдах ], на параметры (объёмы их передачи) можно закрыть глаза. т.ч. тут - "не так уж и нужно".

дедпихто,

хотя вру
асинронность уже снаружи
либо в dblink. либо в ином аналоге клиента, скажем перловом

Sasha AliasНедоступность ноды - это инцидент. В случае RUN ON ALL мне кажется это нельзя игнорировать. Хотя конечно, зависит от приложения. В случае RUN ON ANY это действительно nice to have, т.к. никак не избавляет приложение от умения обрабатывать исключения.
Вцелом, писание "обертки" для plpoxy вполне себе общепринятая практика и даже более того - фишка. Это позволяет написать пост-обработчик на прокси c использованием SQL. В случае, когда обертка не нужна, plproxy не представляет особых преимуществ перед управлением шардингом на уровне приложения или любом другом проксирующем уровне.давай, вася
все уже заждались
не хер тут идеологию толкать, иди работу работать

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