2010/9/9 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>
it's only one request from two mayor request
* transaction handling
* unbound SELECTs and multirecordset support
and some more classic handling of OUT variables.
Pavel
>> Or is the VOID-returning FUNCTION going to be deprecated or
>> discouraged at the same time?
>
> Certainly not.
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>