Re: returning multiple result sets from a stored procedure

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

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