Re: Stored procedures and out parameters

> Shay>Npgsql currently always sends a describe as part of statement
> execution (for server-prepared messages the describe is done only once, at
> preparation-time). Vladimir, are you doing things differently here?
>
> The same thing is for pgjdbc. It does use describe to identify result row
> format.
> However, "CALL my_proc()" works just fine with current git master for both
> simple and extended protocol.
>

In one way that's good, but I wonder how this squares with the following
written by David above:

> 1. A stored procedure should be able to return multiple resultsets with
different structures.
> 2. A stored procedure can decide dynamically of the structure of the
resultset(s) it returns, and the caller will discover it as they're
returned, not before.

Both of the above seem to be simply incompatible with the current
PostgreSQL protocol. Describe currently returns a single RowDescription,
which describes a single resultset, not more. And as I wrote before, I
don't see how it's possible with the current protocol for the caller to
discover the structure of the resultset(s) "as they're returned" - type
information simply isn't included in the responses to Execute, only field
lengths and values. It also leads me to wonder what exactly is returned in
the current implementation when Describe is send on a stored procedure
call: something *is* returned as Vladimir wrote, meaning that stored
procedures aren't as dynamic as they're made out to be?

To summarize, it seems to me that if the multiple resultsets and/or dynamic
resultset structure are a real feature of stored procedure, attention must
be given to possible impact on the protocol and especially how client-side
drivers are supposed to interact with the resultsets.

The missing part is "invoke functions via CALL statement".
>

I agree. This is definitely not a JDBC-specific issue - I'm guessing most
database APIs out there have their (single) way to invoke server-side code,
and that way is currently set to send SELECT because only functions existed
before. The distinction between stored functions and stored procedures
seems to be PostgreSQL-specific, and the different invocation syntax causes
a mismatch. Hope you consider allowing invoking the new stored procedures
with CALL.