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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2010-09-09 20:17:43 | Re: returning multiple result sets from a stored procedure |
Previous Message | Magnus Hagander | 2010-09-09 20:16:30 | Re: [BUGS] BUG #5305: Postgres service stops when closing Windows session |