Tom Lane wrote:
Darren Duncan <dar...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
