Pavel Stehule wrote:
> there are lot of questions - and I am not sure if procedures
> implementation can be done in one release cycle. The basic questions:
>
> * should be special catalog for procedures or we will use pg_proc?
> * how can be implemented OUT variables - the original implementation
> is simple - it's just pointer, but it's not directly possible inside
> postgres, because we use a MemoryContexts?
> * how can be implement a CALL statement - as plan statement or as command?
> * how can be implemented variables inside psql console, if we allows them?
> * how can be implement an overloading of procedures - can we use for
> selection OUT variables too?
> * what is procedure? It's like void function, or it can return status
> code like procedures in SQL/PSM (DB2)?
>
> --- As long years a stored procedures developer, I can say, so just
> minimal implementation of procedures can help with writing little bit
> more readable code for functions that return more then one scalar
> result. But other features can be nice too - explicit transaction
> control and unbind selects. But these features are killing gun.
I've often considered that the main distinction between a function and a
procedure is that the former is intended to be invoked as a value-resulting
expression while the latter is intended to be invoked as a non-value-resulting
statement. The SQL standard uses separate FUNCTION and PROCEDURE for these.
Since Pg's FUNCTION already seems to take on both roles, so overloading the
meaning of the FUNCTION keyword, like what a C function or a Perl sub does,
where returning VOID means procedure, then what is being added by a distinct
PROCEDURE? Or is the VOID-returning FUNCTION going to be deprecated or
discouraged at the same time?
-- Darren Duncan