On 16/08/2018 00:50, Shay Rojansky wrote:
> >> 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.
>
>
> It would be good to understand why you think it's useless (am not
> familiar at all with JDBC, am genuinely interested).
I think this is all coming from Microsoft. The JDBC driver API was
modeled after the ODBC API, and the ODBC specification also contains the
{call} escape. Microsoft SQL Server is also the only SQL implementation
to handle this stored function/procedure stuff totally differently: They
only have procedures, but they return values, and they are invoked by an
EXEC command. (They don't support transaction control AFAIK.) The .NET
stuff is obviously also from Microsoft.
So from Microsoft's perspective, this makes some sense: They only have
one invokable object type, and their invocation syntax is different from
everyone else's. So they made a compatibility wrapper in their client
libraries.
Everyone else, however, has two invokable object types and standard ways
to invoke them. And they all seemingly faced this problem of how to jam
these two into this one hole provided by the JDBC spec and ended up with
slightly different, and incompatible, solutions.
I think, if you want to write a portable-sans-Microsoft JDBC
application, you can just run CALL or SELECT directly. If you want to
write something that is compatible with Microsoft, you can map {call} to
a function invocation as before, which is actually more similar to a
procedure in MS SQL Server.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
