On 11 Sep 2001, Gunnar [iso-8859-1] R�nning 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