Re: returning multiple result sets from a stored procedure

2010/9/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Darren Duncan <darren(at)darrenduncan(dot)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.
>

it's only one request from two mayor request

* transaction handling
* unbound SELECTs and multirecordset support

and some more classic handling of OUT variables.

Pavel

>> Or is the VOID-returning FUNCTION going to be deprecated or
>> discouraged at the same time?
>
> Certainly not.

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>