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.