Re: returning multiple result sets from a stored procedure

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Darren Duncan" <darren(at)darrenduncan(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: returning multiple result sets from a stored procedure
Date: 2010-09-09 20:25:58
Message-ID: 4C88FC8602000025000354A1@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.

That is the biggest distinction in my mind, too. Supporting
multiple result sets just as if the queries were run as independent
client-side statements would also be very important. I have seen
implementations which support, for a single stored procedure, OUT
parameters, a RETURN value, and multiple result sets -- all at the
same time, as separate things. I haven't reviewed stored procedures
in the SQL standard since an early draft proposal years ago, so I
don't know what the current state of that is, but if PostgreSQL
approaches this, it'd be nice to implement as many of the above as
are not in conflict with requirements of the standard.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-09-09 20:29:45 Re: returning multiple result sets from a stored procedure
Previous Message Pavel Stehule 2010-09-09 20:22:42 Re: returning multiple result sets from a stored procedure