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 Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
