"Andrey Feklistov" ...
>
> > Я половину не понял, но всё равно это не проще :)
> Можно, я тут мыслями помусорю? :) Попробуем на примерном синтаксисе.
>
> create procedure p1(...) returns (...) as
> declare sales cursor ...
> begin
> ...
> open sales;
> rdb$set_context('USER_TRANSACTION', 'dataflow', sales);
> for select res_string from p2 into :output_param1 do
> suspend;
> ...
> end
>
> create procedure p2 returns (...) as
> ...
> begin
> ...
> incoming_stream=rdb$get_context('USER_TRANSACTION','dataflow');
> fetch incoming_stream into ...;
> ...
> suspend;
> end
Зачем изобретать изобретённый велосипед ? :) И зачём тут rdb$set_context ?
Передача курсоров через параметры и\или переменные полностью решает эту
задачу (с точки зрения синтаксиса языка). Проблемно тут будет динамически
разрешать имена полей, но, в принципе, это должно быть решаемо, имхо
> Т.е. одинаковую обработку _массивов_ данных можно будет отделить от
> подготовки данных. И если у нас есть процедура, осуществляющая
> статистический расчет (да хотя бы среднеквадратичное отклонение), то не надо
> ее код дублировать везде, где нужно по потоку данных среднеквадратичное
> отклонение посчитать. Можно подготовить курсор, выполнить процедуру и иметь
> счастье. Это что-то типа передачи курсора как параметра в процедуру, только
> в таком варианте это чуть более мощная возможность.
Почему в таком варианте более мощная ?
> На самом деле я прекрасно понимаю, что часть подобных вопросов закрывает ES
> (хотя с такими потерями..), часть - GTT (это должно быть уже без серьезных
> потерь). Но если уж мы говорим о SQL сервере, то вообще-то как раз
> оперирование с результирующими потоками идеологически вернее. IMHO, само
> собой.
Как это сделать в стиле и духе SQL - вот вопрос
--
Хорсун Влад
