On 12/08/2018 09:51, Shay Rojansky wrote:
> Would it be possible for you to review the following two questions? Some
> assertions have been made in this thread about the new stored procedures
> (support for dynamic and multiple resultsets) whose compatibility with
> the current PostgreSQL protocol are unclear to me as a client driver
> maintainer... Some clarification would really help.
Stored procedures in PostgreSQL currently do not support dynamic or
multiple result sets. Multiple result sets is a possible future
feature, which would work within the existing protocol. Dynamic result
sets in the sense that the structure of the result set is determined at
execution is not something I'm planning, so I can't comment on how that
might work. (In the SQL standard, the term "dynamic result sets" is
used in the sense of "possibly multiple result sets".)
> Also another request by Vladimir and myself to consider allowing
> functions to be invoked with CALL, in order to provide a single way to
> call both procedures and functions - this is important as language
> database APIs typically have a single, database-independent way to
> invoke server-side code that does not distinguish between functions and
> procedures.
I am familiar with the Java {call} escape. But I think it's pretty
useless. You're not going to get any compatibility with anything from
it, since every SQL implementation does something different with it, for
the exact reason that you allude to: functions and procedures are
different objects in SQL, and this interface is trying to jam them both
into one.
If you are currently mapping {call foo()} to SELECT * FROM foo(), I
think that's fine and you can continue doing that. If you want to call
a procedure (created with CREATE PROCEDURE), just invoke CALL directly
without any escape syntax.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services