Re: WIP patch: convert SQL-language functions to return tuplestores
От | Tom Lane |
---|---|
Тема | Re: WIP patch: convert SQL-language functions to return tuplestores |
Дата | |
Msg-id | 16220.1225381530@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP patch: convert SQL-language functions to return tuplestores (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP patch: convert SQL-language functions to return tuplestores
|
Список | pgsql-hackers |
I wrote: > I'm currently going to have a look at just what it would take to support > both lazy and eager evaluation in functions.c (independently of what > syntax, if any, we settle on to expose the choice to the user). If it's > either really awful or really easy we should know that before arguing > further. Attached is a draft patch that allows SQL functions to return sets using either value-per-call or materialize mode. It does not expose any control to the user; for the moment, the choice is driven by whether the call site is ExecMakeFunctionResult (which prefers value-per-call) or ExecMakeTableFunctionResult (which prefers materialize). I estimate that functions.c is two or three hundred lines longer than it would be if we stripped the value-per-call support and simplified the logic down to what I had in my prior patch. Which is not all that much in the big scheme of things, so I'll withdraw my argument for simplifying. I'm not sure if it's worth adding a control knob or not --- it's still true that materialize is faster on a tuple-by-tuple basis, but whether the difference is all that significant for nontrivial queries is debatable. Anyway I don't really want to work on that point right now. The next step is to make it actually support RETURNING queries, and if I don't get on with that I won't finish it before commitfest. regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: