Skip site navigation (1) Skip section navigation (2)

Re: returning multiple result sets from a stored procedure

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Darren Duncan <darren(at)darrenduncan(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: returning multiple result sets from a stored procedure
Date: 2010-09-09 20:44:18
Message-ID: AANLkTinmjH0zT+7ZnJyimCSq0chtmHU8Fb6PjCmKN2q3@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/9/9 Darren Duncan <darren(at)darrenduncan(dot)net>:
> Tom Lane wrote:
>>
>> Darren Duncan <darren(at)darrenduncan(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-09-09 20:46:49
Subject: Re: returning multiple result sets from a stored procedure
Previous:From: Darren DuncanDate: 2010-09-09 20:35:07
Subject: Re: returning multiple result sets from a stored procedure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group