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 415EF3BE.4020105@joeconway.com
Whole thread Raw
In response to SQL-Invoked Procedures for 8.1  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: SQL-Invoked Procedures for 8.1
List pgsql-hackers
Gavin Sherry wrote:
> That's fairly bizarre (at least to my view of the world). Say we could
> have OUT parameters which were of some SETOF style type I think that would
> solve the same problem.

That won't satify people moving over from MSSQL/Sybase, but then again, 
maybe the community at-large doesn't think it is important to satify 
that group of users.

I think this part of the thread actually ties in with the discussion 
regarding beginning/committing transactions within stored procedures. 
Think of a stored procedure as a parameterized sql script that is run 
from within a single statement, rather than as a series of statements 
piped in from a file. In such a file, you might do
  begin;  INSERT ...;  UPDATE ...;  commit;  SELECT ...;  CREATE TEMP TABLE foo AS SELECT ...  UPDATE ...;  SELECT
...;

in order to perform a series of actions while being able to see interim 
results. In MSSQL, a stored procedure can be (and very often is) used to 
do something exactly like the above (perhaps related to loading of a 
data warehouse, or in an interface between two business systems). In 
fact, T-SQL (the MSSQL/Sybase SQL variant) also supports simple 
branching, variable assignment, and conditionals, which makes it 
possible to do some fairly complex processing in stored procs. This is 
the direction I always hoped Postgres would go with stored procedures.

Joe




pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: SQL-Invoked Procedures for 8.1
Next
From: Gaetano Mendola
Date:
Subject: Re: Mislabeled timestamp functions (was Re: [SQL] [NOVICE] date_trunc'd