Joe,
> This isn't isolated to just PL/pgSQL, just like the ability to create
> and call functions isn't. Support for PROCEDUREs in the backend is a
> prerequisite to being able to use PL/pgSQL to create procedures. It is
> necessary but not sufficient.
>
> Similarly, if we want to support IN/OUT or named parameters, it isn't a
> PL/pgSQL issue per se, it is a general one.
Sure. But the ability to call in/out parameters (which would also be tied to
calling the parameters by name, etc) is pretty useless without supporting
them in one of the PLs. And PL/pgSQL is the natural place to start, since it
gives a migration path to DBAs with Oracle or MSSQL applications which make
heavy use of procedures.
FWIW, my vision of "how procedures are different from functions" goes:
1) no overloading, permitting the calling of an SP with some but not all of
its params;
2) no implicit transaction, allowing (maybe requiring?) begin/commit/rollback,
and even vacuum, in an SP.
3) named parameters, callable by name from the client;
4) exception handling of some sort (either T-SQL's immediate-response model or
the more robust "on exception" model from PL/SQL).
5) Cannot be called as a part of a larger query (required by (2) above)
--
-Josh BerkusAglio Database SolutionsSan Francisco