| From: | "Robert Haas" <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
| Subject: | Re: WIP patch: convert SQL-language functions to return tuplestores |
| Date: | 2008-10-29 13:07:34 |
| Message-ID: | 603c8f070810290607t7f00bd1bud8865e7a376fe7ca@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> So my idea would be to have the SQL function behavior choose to return values
> either via tuplestore or via value-per-call, depending on the user
> setting "generator" or "lazy".
> Done this way, the user could also choose for the function to be lazy or to
> use a tuplestore whatever the language in which it's written.
The problem is not the general PostgreSQL executor, but whatever body
of code executes PL/pgsql functions (and other PL languages). It does
not, as I understand it, support freezing execution of the function
midway through and picking up again later. I haven't looked at the
code, but based on previous experience, that could turn out to be a
pretty major refactoring. I suspect it would be worthwhile and quite
welcome to many users - but I doubt very much that it would be easy.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2008-10-29 13:17:18 | Re: Updating FSM on recovery |
| Previous Message | Greg Smith | 2008-10-29 13:05:21 | Re: Decreasing WAL size effects |