From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Joe Conway <mail(at)joeconway(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PROCEDURES was: TODO items |
Date: | 2003-08-08 17:49:53 |
Message-ID: | 200308081049.53912.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2003-08-08 18:01:04 | Re: new psql \d command |
Previous Message | Bruce Momjian | 2003-08-08 17:42:25 | Re: src/interfaces/cli |