Re: WIP patch: convert SQL-language functions to return tuplestores
| От | Tom Lane |
|---|---|
| Тема | Re: WIP patch: convert SQL-language functions to return tuplestores |
| Дата | |
| Msg-id | 19184.1225200408@sss.pgh.pa.us обсуждение |
| Ответ на | Re: WIP patch: convert SQL-language functions to return tuplestores (Gregory Stark <stark@enterprisedb.com>) |
| Ответы |
Re: WIP patch: convert SQL-language functions to return tuplestores
Re: WIP patch: convert SQL-language functions to return tuplestores |
| Список | pgsql-hackers |
Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.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
В списке pgsql-hackers по дате отправления: