Proposal: real procedures again (8.4)

Hello,

I found lot of discus about this topic.

http://www.postgresql.org/docs/faqs.TODO.html
http://archives.postgresql.org/pgsql-hackers/2003-08/msg00501.php
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00734.php
http://archives.postgresql.org/pgsql-hackers/2004-08/msg00872.php
http://archives.postgresql.org/pgsql-hackers/2004-09/msg00702.php

There is one result - OUT params for functions. I propose start with
simple goals that we can enhance in future.

First goal: Procedures support for better conformance with ANSI SQL:

* procedure returns any only through OUT, INOUT params,
* procedure has own executor, that allows byref params (and own
transaction management in future),
* procedure can be overloaded,
* procedure can not returns recordset or multi recordset,
* procedure doesn't support default parameters,
* SQL statement CALL allows only expression (this proposal doesn't
need session variables) for older environments
* new SPI_exec_procedures API (allows binding to host variables) and
some similar in libpq, that allow CALL implementation in pgsql and
others.
* new internal exec_exec_proc (allow ref on datum variable) used in
plpgsql statement CALL.
* new V2 calling convention (maybe based on SQL/CLI)
* no changes in current functions support

Later:
* procedure can manages transactions,
* procedure can returns recordset or multi recordset,
* procedure allows default parameters,
* CALL statement allows session variables
* no changes in current functions support

Why new calling convention? I would to support byref variables and
then I have to carry memory context info ... and maybe some others

Nice a weekend

Pavel Stehule

p.s.

Why procedures? New parts of ANSI SQL use it, and what is worse, they
use methods:
http://www.wiscorp.com/H2-2005-350-WG4-wlg005-Part-7-History-2nd-Edition-Text-for-Working-Draft.pdf