> 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.
"Stored Procedure".. Hmm, that seems to me that the definition of that would
be "a procedure that's stored somewhere". When talking about stored
procedures and databases I would assume that the stored procedure would be
some database procedure (anything you can do with or in a database could be
seen as a procedure, IMHO), that's stored in the said database...
"Stored Procedure" is a very ambiguous term and probably needs to be treated
as such.. Unless there is a written definition somewhere that outlines
exactly how a stored procedure has to return things then I think PG's stored
procedures have the right to carry the name...
> 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.
What do they base that on though? The inability to return a record set from
a PG stored procedure is a limitation, no doubt, but not cause to say that
PG doesn't support stored procedures..
> 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.
I think PG is using the term as well as anyone could use such an
ambiguous term.. I think it's fair to list the limitations of PG stored
procedures when discussing feature sets but I don't think it's fair to say
that PG doesn't have stored procedures as clearly it does!
-Mitch
