Re: SQL-Invoked Procedures for 8.1 - Mailing list pgsql-hackers

From Joe Conway
Subject Re: SQL-Invoked Procedures for 8.1
Date
Msg-id 4152F21F.5080502@joeconway.com
Whole thread Raw
In response to Re: SQL-Invoked Procedures for 8.1  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: SQL-Invoked Procedures for 8.1  (Maarten Boekhold <boekhold@emirates.net.ae>)
Re: SQL-Invoked Procedures for 8.1  (Neil Conway <neilc@samurai.com>)
Re: SQL-Invoked Procedures for 8.1  (Gavin Sherry <swm@linuxworld.com.au>)
List pgsql-hackers
Gavin Sherry wrote:
> Do you have any idea about databases returning result sets from SQL
> procedures (ie, not functions).
> 

As other's have pointed out, this is very common in the MS SQL Server 
world (and I believe Sysbase also supports it). It works like:

<begin proc def>

select * from something
...
select * from somethingelse
...

<end proc def>

We get requests for this kind of functionality at least a couple of 
times a month, and although it's been a few years since I mucked with 
MSSQL, I found it to be very useful in a number of different circumstances.

It is only workable because stored procedures cannot participate in 
normal SELECT statements. In MSSQL you would do something like:
  exec sp_my_multiresultset_proc  GO
-- or --  sp_my_multiresultset_proc  GO

so the analogy to your stored procedure proposal holds:
  call sp_my_multiresultset_proc();
-- or --  sp_my_multiresultset_proc();

I had always envisioned implementing this by projecting tuples directly 
the way that SHOW ALL or EXPLAIN ANALYZE do. See, e.g. 
ShowAllGUCConfig() in guc.c.

Joe


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Use of zlib
Next
From: Fabien COELHO
Date:
Subject: Re: BUG: possible busy loop when connection is closed