Re: returning multiple result sets from a stored procedure
От | Tom Lane |
---|---|
Тема | Re: returning multiple result sets from a stored procedure |
Дата | |
Msg-id | 5455.1284063396@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: returning multiple result sets from a stored procedure (Darren Duncan <darren@darrenduncan.net>) |
Ответы |
Re: returning multiple result sets from a stored procedure
Re: returning multiple result sets from a stored procedure Re: returning multiple result sets from a stored procedure Re: returning multiple result sets from a stored procedure |
Список | pgsql-hackers |
Darren Duncan <darren@darrenduncan.net> writes: > Since Pg's FUNCTION already seems to take on both roles, so overloading the > meaning of the FUNCTION keyword, like what a C function or a Perl sub does, > where returning VOID means procedure, then what is being added by a distinct > PROCEDURE? You might care to go back and re-read some of the extensive prior threads about this, but to my mind the main thing that would justify inventing a separate PROCEDURE facility is if procedures were to execute outside the transaction system, so that they could start and stop transactions for themselves. This is unlike a function which necessarily executes inside an already-running transaction. Of course a lot of questions would need to be answered about error-handling behavior and so forth, but that's a capability that a LOT of people have asked for. > Or is the VOID-returning FUNCTION going to be deprecated or > discouraged at the same time? Certainly not. regards, tom lane
В списке pgsql-hackers по дате отправления: