From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vadim Menshakov <vadim(at)price(dot)ru>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: table function: limit, offset, order |
Date: | 2003-03-22 19:12:53 |
Message-ID: | 3E7CB5B5.2040908@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ed L. | 2003-03-22 19:57:01 | Re: 32/64-bit transaction IDs? |
Previous Message | Tom Lane | 2003-03-22 19:00:16 | Re: 32/64-bit transaction IDs? |