> "Sergey E. Koposov" <math@sai.msu.ru> writes:
> > LOOP
> > FETCH cur into rec;
> > RETURN NEXT rec;
> > EXIT WHEN NOT FOUND;
> > END LOOP;
> > RETURN;
>
> Don't you think you should have the EXIT *above* the RETURN NEXT?
> I would expect this to emit a bogus row of nulls after the last row
> returned by the cursor. (At least that's what I get with current
> sources. Pre-8.0 it might return the last row twice.)
Yes, surely EXIT should be written before RETURN NEXT, it was my error,
(thanks, but I've found that error by myself, after posting my message)
But that small bug does not affect the original problem.
> Running it on a 500-million-row table would quite possibly run out of
> memory or disk space, too, because RETURN NEXT accumulates all the
> results before the function is actually exited.
Yes, that's right, but I did not waited until the whole table was loaded in
the function. The error, which is the subject of current thread occured
just immediately after "select * from yyy()", so surely was not caused by
memory overfilling.
Concerning to the exact form of my functions (using cursors, but still
collecting all the data in the memory). As I understand this is the only one
way (or just the simplest way ???)
to execute fully dynamic queries returned by C function in PL/SQL.
For the real functions which I use, instead of
query = ''SELECT * FROM usno'';
I have
query = my_C_function(some_args);
(see full code in my first message)
------------------------------------------------------------
Sergey E. Koposov
Sternberg Astronomical Institute, Moscow University (Russia)
Max-Planck Institute for Astronomy (Germany)
Internet: math@sai.msu.ru, http://lnfm1.sai.msu.su/~math/
