Anonimowy blok nie może niczego zwrócić. Możesz przypisać wartości do zmiennej wiążącej, w tym typu kolekcji lub kursora ref, wewnątrz bloku. Ale kolekcja musiałaby być zdefiniowana, a także zadeklarowana poza blokiem. Oznacza to, że musiałby to być typ, którego można użyć w zwykłym SQL, a nie coś zdefiniowanego w PL/SQL. W tej chwili używasz typu PL/SQL, który jest zdefiniowany w bloku, a także zmiennej, która jest zadeklarowana w bloku - więc jest poza zasięgiem klienta i nie byłby prawidłowym typem poza nim . (Nie trzeba go również inicjować, ale to drobny problem).
W zależności od tego, w jaki sposób zostanie on rzeczywiście wykorzystany, jedną z opcji jest użycie kursora ref, który można zadeklarować i wyświetlić za pomocą SQL*Plus lub SQL Developer z variable i print polecenia. Na przykład:
variable rc sys_refcursor
begin
open :rc for ( select ... /* your cursor statement */ );
end;
/
print rc
Możesz zrobić coś podobnego z aplikacji klienckiej, np. mieć funkcję zwracającą kursor ref lub procedurę z parametrem out, który jest kursorem ref i powiązać go z aplikacją. Następnie wykonaj iterację kursora ref jako zestaw wyników. Ale szczegóły zależą od języka używanego w aplikacji.
Inną opcją jest posiadanie funkcji potokowej, która zwraca typ tabeli - ponownie zdefiniowany na poziomie SQL (za pomocą create type ) nie w PL/SQL - co może zużywać mniej zasobów niż kolekcja zwracana za jednym razem.
Ale musiałbym zapytać, dlaczego to robisz. Powiedziałeś, że „wykopywanie kolejnych partii zajmuje znacznie więcej czasu”, co brzmi tak, jakbyś używał mechanizmu stronicowania w zapytaniu, generując numer wiersza, a następnie wybierając zakres 100 w tym zakresie. Jeśli Twój klient/aplikacja chce pobrać wszystkie wiersze, łatwiej byłoby wykonać pojedyncze zapytanie, ale pobrać wynik ustawiony w partiach.
Niestety bez informacji o aplikacji to tylko spekulacje...
