Tom Lane wrote:
> This is one of the limitations of the present table function
> implementation; there should be a way for the function to return one row
> per call. (We talked about that back in the early stages of the table
> function project, but it remains undone.) Given that, a LIMIT would
> simply cause the executor to stop fetching rows from the function.
Yup, I remember that.
> I'm not sure the plpgsql implementation could support such an operating
> mode, but the SQL-function implementation could do it easily; and of
> course C functions could do it if they don't mind saving their state
> from call to call.
It would be really ugly to get a stream mode working for plpgsql (or
plr, pltcl, plperl, plpython, etc for that matter), but it does seem
ultimately desirable for sql and C.
> Actually, the pieces are all in place for this already, now that
> TupleStore can support interleaved read and write. For a set function
> using the row-per-call behavior, it'd be possible to run the function
> only when new rows are actually demanded from the FunctionScan node.
> However, making this work in parallel with the single-call-returns-a-
> TupleStore mode could make the code pretty ugly...
I always intended to get back to this, and it seems your recent
innovations will make it easier. I'll be mired in the array support
coding for at least a few weeks (although I hope to have a "phase 1"
patch in by Monday), but after that I'll try to pick back up on the
table function streaming mode support.
Joe
