I found lot of discus about this topic.


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
* 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

* 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


Why procedures? New parts of ANSI SQL use it, and what is worse, they
use methods:

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to