Re: PROCEDURES was: TODO items - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: PROCEDURES was: TODO items
Date
Msg-id 200308081049.53912.josh@agliodbs.com
Whole thread Raw
In response to Re: TODO items  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: new psql \d command
Next
From: Bruce Momjian
Date:
Subject: Re: src/interfaces/cli