Re: table function: limit, offset, order
От | Joe Conway |
---|---|
Тема | Re: table function: limit, offset, order |
Дата | |
Msg-id | 3E7CB5B5.2040908@joeconway.com обсуждение исходный текст |
Ответ на | Re: table function: limit, offset, order (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-general по дате отправления: