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

Dimitri Fontaine <dfontaine(at)hi-media(dot)com> writes:
> Le mercredi 29 octobre 2008, Tom Lane a crit:
>> So the fact that it's possible for SQL-language functions is an
>> idiosyncrasy of that language, not something we should cram into the
>> general CREATE FUNCTION syntax in the vain hope that having syntax
>> might cause an implementation to appear someday.

> Ok, that confirms that lazy evaluation and call-per-value are distinct things,
> for once, and that what you where after was not an easy syntax bit. :)

Well, call-per-value is *necessary* for lazy evaluation, but it's not
*sufficient*. You need a function implementation that can suspend and
resume execution, and that's difficult in general.

>> Therefore, if we were going to expose a knob to the user to control this
>> behavior, I'd be inclined to make it a part of the language-specific
>> syntax of SQL function bodies.

> How would we support the option for SQL functions?

Well, we'd just tweak how the executor gets called inside functions.c.
The main problem is that we'd have to have two different sets of
behavior there, depending on whether we are trying to evaluate commands
a row at a time or all at once, plus interlocks to disallow cases like
using LAZY with a RETURNING query. It's certainly possible but I
believe it will make functions.c a lot longer and uglier than it would
be without it.

>> Mind you, I'm not exactly *for* this, because I think it will result
>> in making functions.c a whole lot more complex and hard to maintain
>> than it needs to be, in exchange for a behavior that I don't believe
>> is especially useful in most cases, and can easily be worked around
>> when it is useful.

> From what I understand, the lazy evaluation of functions is not seen as easy
> to be worked around by people asking for it.

Nobody has refuted the argument that sticking a LIMIT into the function
would accomplish the same result.

> What's against PLpgSQL implementing a YIELD statement?

Feel free to try it, if you want. When you get done you might have some
grasp of why it'll be nearly impossible for PLs that we don't control
the entire implementation of.

regards, tom lane