Re: returning multiple result sets from a stored procedure

Tom Lane wrote:
> 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.

That is a very strong rationale in my mind to have clearly distinct kinds of 
routines, where one kind is implicitly entirely contained in a transaction and 
the other kind can cross transaction boundaries or control transactions.  I 
support the separation on those grounds alone, though it also makes sense that 
the 2 kinds can have additional ways to distinguish them. -- Darren Duncan