2010/9/9 Tom Lane <t...@sss.pgh.pa.us>: > 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. >
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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
