Re: Ridicolus Postgresql review

On 11 Sep 2001, Gunnar [iso-8859-1] Rnning wrote:

> * Peter Eisentraut <peter_e@gmx.net> wrote:
> 
> | server.  PostgreSQL supports both of these things just fine.  A whole
> | 'nother thing is the ability to return result sets from functions.
> | 
> | OK, other vendors may call the latter for "stored procedures", but that is
> | terminological nonsense.  And going out there writing an article claiming
> | that in PostgreSQL "users do not have the ability to create their own
> | stored procedures", without further qualification, is confusing at best.
> 
> 
> That's not nonsense at all, you can't just go around and redefine the
> language used in the database world at your own whims. 
> 
> Everybody I know employed in the database arena thinks of a stored procedure
> as something that may return result sets. In PostgreSQL it cannot and 
> does therefore not fit the term stored procedure.
Its a limitation, which is currently being worked on. Everywhere _I_ work,
stored procedure is just that, a function stored inside the server that
does some useful work.

> What is confusing is the PostgreSQL use of the term "stored
> procedure". To me it sounds like bad marketing, something we really
> shouldn't need in the open source world.

a) You CAN return result sets already (sort of) by returning a cursor,
then doing 'fetch all from cursor'. Its not quite standard, but its
possible.

b) Soon enough you'll be able to do 'select * from func(args)', half of
the code is already written and being committed.  Its a question whether I
will be able to finish it and get it in 7.2, but at any case, soon this
minor limitation will be removed.

-ale