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 по дате отправления: