Re: Proposal: real procedures again (8.4)

2007/10/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2007/10/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >> Most of that sounded to me like a proposal to re-invent ecpg. If there
> >> were such a large demand for doing things that way, there would be many
> >> more users of ecpg than bare libpq. AFAICT, though, *very* few people
> >> use ecpg.
>
> > With procedures we can be in conformance with ANSI standard and others
> > databases.
>
> [ shrug... ] If you want us to buy into supporting parts of the SQL spec
> other than Part 2, you need to make a case why --- the argument that
> "it's in the standard" cuts no ice at all with me for all that other
> stuff. AFAICS the market demand for ecpg-style APIs is nil.
>

My goal is well support of SQL/PSM and well support of stored
procedures. Conformance with ANSI is nice secondary effect.
Actually, current model of OUT params is dificult for learning, for
develop too (in C), and it's rare. I like it for functions, it is
really good idea, but isnot easy (and sometimes is limiting (in
overloading))

I cannot do:
CREATE PROCEDURE foo(IN a int, OUT b varchar)
CREATE PROCEDURE foo(IN a int, OUT b integer)

sample:
CREATE FUNCTION foo(out a int, out b int)
BEGIN
a := 10;
b := 30;
END;

CREATE FUN caller(out a int, out b int)
BEGIN
SELECT INTO a,b foo()
END;

Try to write these function in C.

With procedures it can be:

int
foo(PG_PROCEDURE_CALL)
{
PG_SETARG_INT32(Int32GetDatum(10));
PG_SETARG_INT32(Int32GetDatum(30));

return 0; /* exit status */
}

int
caller(PG_FUNCTION_CALL)
{
heapTuple
.....

if (0 == DirectProcedureCall(DATUMBYREF(&a),
DATUMBYREF(&b)))
{

}
...

Regards
Pavel Stehule