Recursive calls works in PL/Java. No problem there. But the larger the
set, the more memory it consumes. Do I read your answers correctly if I
conclude this is a known limitation when SPI is used? I.e. there's no
way to stream one row at a time without ever building the full set?
Regards,
Thomas Hallgren
Andrew Dunstan wrote:
Tom Lane wrote:
plpgsql and similar languages will return a tuplestore anyway, so it has
to handle that case, and it was convenient to make all the cases look
alike for starters. Nobody's yet gone back to improve it for the case
of languages that return a tuple per call.
This would be hard to do in the plperl case, at least, and I would be
surprised if it weren't in most others too. So what plperl does is to
fetch the whole set on the first call and then fudges all the other
calls to get the next element from the result set. We save out the
intermediate tuple store on each call and restore it afterwards, so I
think recursion shouldn't be a difficulty.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
