Le mercredi 29 octobre 2008, Tom Lane a écrit : > 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.
Ok, I think I begin to understand how things are tied together. Thanks again for your patience explaining :) > 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. And I fail to see how the user would control which behavior will get chosen, which I think was part of the "going further with your ideas" sub thread. > Nobody has refuted the argument that sticking a LIMIT into the function > would accomplish the same result. Fair enough. > > What's against PLpgSQL implementing a YIELD statement? > > Feel free to try it, if you want. Hehe, not this year. But being able to ask questions and get clarifications from hackers certainly is a step in this direction. Feeling ready and organizing one's time around it is the next :) > 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. Hence the YIELD / new API idea, with the LAZY property which would be optional for PLs and only implemented in plpgsql (and maybe plpython, as python supports the generator functions concept) first. Maybe having optional features for PLs has not yet been done? But again, I was started in this only by misunderstanding your call here: > I think the PL side of the problem is the hard part --- if we knew how > to solve these issues for plpgsql then SQL functions would surely be > easy. I'm not being sticky on the feature request, just struggling to understand correctly the issues at hand, recognizing that easy choice of EAGER or LAZY function evaluation would be great as a user, even if unsupported in a number of PLs. Regards, -- dim
signature.asc
Description: This is a digitally signed message part.
