2010/9/9 Darren Duncan <darren@darrenduncan.net>:
> Tom Lane wrote:
>>
>> 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.
>
> 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
>