Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)? - Mailing list pgsql-general

From Merlin Moncure
Subject Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?
Date
Msg-id b42b73150810160743j1aac385eq169a09bd5e47f29a@mail.gmail.com
Whole thread Raw
In response to Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: PL/pgSQL stored procedure returning multiple result sets (SELECTs)?  ("Pavel Stehule" <pavel.stehule@gmail.com>)
List pgsql-general
On Wed, Oct 15, 2008 at 5:48 PM, Bruce Momjian <bruce@momjian.us> wrote:
>
> Below is a very good summary of the limitations of our function
> capabilities compared to procedures, e.g.:
>
>        o  no transaction control in functions
>        o  no multi-query return values without using special syntax
>
> I don't think we can cleanly enable the second capability, but could we
> allow transaction control for functions that are not called inside a
> multi-statement transaction?
>
> FYI, right now when you call a function all statements are assumed to be
> in a single transaction, and allowing transaction control inside a
> function would mean that each statement in a function is its own
> transaction _unless_ transaction control is specified.  There would
> certainly need to be special syntax to enable this.
>
> Is there a TODO here?

I don't think so, except that we need a TODO for proper stored
procedure support if there is not one already.  Proper SPs have been
much discussed, Pavel spearheading what effort has been done.

Being able to manually do transactions for functions would be nice
certainly, but I suspect this is a big part of the challenge for
proper SPs.

merlin

pgsql-general by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Drupal and PostgreSQL - performance issues?
Next
From: "Roderick A. Anderson"
Date:
Subject: Re: Problems with Timezones in Australia