| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| 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>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "Robert Haas" <robertmhaas(at)gmail(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 17:19:50 |
| Message-ID: | 3909.1225300790@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le mercredi 29 octobre 2008, Tom Lane a crit:
>> However, I see no
>> solution to that problem except function inlining; and if the function
>> gets inlined then all this discussion is moot anyhow.
> How to inline PLs functions?
All of this is pie-in-the-sky for PL functions, and I think properly so:
the whole reason for supporting PLs is to enable doing things that SQL
does poorly or not at all. So expecting SQL to interoperate very
closely with them seems impossible, or at least unreasonably limiting.
The real issue at hand is what to do with SQL-language functions.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2008-10-29 17:24:26 | Re: WIP patch: convert SQL-language functions to return tuplestores |
| Previous Message | Hannu Krosing | 2008-10-29 17:17:42 | Re: pre-MED |