Re: PROCEDURES was: TODO items
От | Josh Berkus |
---|---|
Тема | Re: PROCEDURES was: TODO items |
Дата | |
Msg-id | 200308081049.53912.josh@agliodbs.com обсуждение исходный текст |
Ответ на | Re: TODO items (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: