Re: WIP patch: convert SQL-language functions to return tuplestores

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

In response to

Responses

Browse pgsql-hackers by date

  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