2010/9/9 Darren Duncan <dar...@darrenduncan.net>: > 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
Functions should be under transaction always, but procedures when people like. There is "BEGIN ATOMIC ... END" block defined in SQL/PSM and procedure can be defined as ATOMIC or non ATOMIC. For me - most important difference is activation - function is activated from SELECT statement - and SELECT has plan - the result is hardly specified, procedure is activated by CALL statement - there are not plan - the result isn't limited. Regards Pavel Stehule > > -- > 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