Skip site navigation (1) Skip section navigation (2)

Re: returning multiple result sets from a stored procedure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Darren Duncan <darren(at)darrenduncan(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: returning multiple result sets from a stored procedure
Date: 2010-09-09 20:16:36
Message-ID: 5455.1284063396@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

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

Certainly not.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-09-09 20:17:43
Subject: Re: returning multiple result sets from a stored procedure
Previous:From: Magnus HaganderDate: 2010-09-09 20:16:30
Subject: Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group