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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
