Re: WIP patch: convert SQL-language functions to return tuplestores

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I suspect it doesn't help you as much as you think. It's always been
>> the case that SRFs in FROM-items are fed through a tuplestore, and so
>> are plpgsql SRF results.

> I always thought we considered that a bug though. It sure would be nice if we
> could generate results as needed instead of having to generate them in advance
> and store all of them.

I suppose, but short of a fundamental rethink of how PL functions work
that's not going to happen. There's also the whole issue of when do
side-effects happen (such as before/after statement triggers).

> In particular I fear there are a lot of places that use functions where we
> might expect them to use views. They're never going to get really good plans
> but it would be nice if we could at least avoid the extra materialize steps.

Agreed, but I think the fundamental solution there, for simple-select
functions, is inlining.

> Now your patch isn't affecting that one way or the other but does it rule it
> out forever?

I think the PL side of the problem is the hard part --- if we knew how
to solve these issues for plpgsql then SQL functions would surely be
easy.

regards, tom lane