From: | Jeff Davis <list-pgsql-general(at)dynworks(dot)com> |
---|---|
To: | "SHELTON,MICHAEL (Non-HP-Boise,ex1)" <michael_shelton(at)non(dot)hp(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Stored procedures vs Functions |
Date: | 2001-12-21 21:20:45 |
Message-ID: | 0GOP00MZ0Q2VBO@mta6.snfc21.pbi.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Friday 21 December 2001 12:27 pm, you wrote:
> Tom,
>
> I've switched topics so I started a new thread, but your last comment about
> 7.2 made me think of a lingering question I've had. I've seen posts about
> stored procedures and functions not being able to return result sets, etc.
>
> In my last job I did e-commerce on a win2k platform with SQL 7.0. We used
> stored procedures extensively and found them to be very advantageous
> (especially on the occasions we need to return 2 different result sets from
> 2 different queries within the stored proc). My question then: are there
> stored procedures that execute like SQL 7.0 stored procs and if so are they
> functions and if so do I need to use a specific language or syntax?
Stored procedures/functions are not able to return result sets. You might be
able to use a combination of functions and views to accomplish your task in a
similar way. Functions and stored procedures are interchangable when refering
to postgres. You can write a stored procedure in any of several built in
languages (PL == procedural language): PL/PgSQL, PL/perl, PL/python, PL/tcl;
alternatively, you can make your own language (although that involves a
considerable amount of effort).
Hope this helps,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-21 21:54:55 | Re: Stored procedures vs Functions |
Previous Message | SHELTON,MICHAEL (Non-HP-Boise,ex1) | 2001-12-21 20:27:30 | Stored procedures vs Functions |