Hi, On 05/10/2011 02:55 PM, Robert Haas wrote: > On Mon, May 9, 2011 at 11:58 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: >> no - you are little bit confused :). CALL and function execution >> shares nothing. There is significant differences between function and >> procedure. Function is called only from executor - from some plan, and >> you have to know a structure of result before run. The execution of >> CALL is much simple - you just execute code - without plan and waiting >> for any result - if there is.
I think the distinction between function and procedure is misleading here. Some envision stored *procedures* to be able to return values, result sets and possibly even *multiple* result sets. > The main features seem to be (1) explicit transaction control > and/or execution of commands like VACUUM that can't be invoked from > within a transaction, I think that's the main point of stored procedures. > (2) autonomous transactions To me autonomous transactions seem orthogonal. Those can be used to implement (1) above, but might have other uses for regular transactions as well. (The point I'm taking home here is that you might want to control not only one concurrent transaction, but several from a "stored procedure". So far, I assumed only one.) > and (3) returning > multiple result sets. But I don't think anybody would be desperately > unhappy if it magically became possible to do those things from > regular functions, unlikely as that may seem. That point definitely is on my wish-list for UDFs already. I didn't think of this as having to do with stored procedures, either. Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
