Re: Stored procedures and out parameters

>to compensate for the decisions made by the JDBC driver PostgreSQL

It is not a decision by PostgreSQL JDBC driver. It is a decision by JDBC
(Java Database Connectivity) specification itself.
pgjdbc just follows the specification there.

Well, there's an initiative for a new JDBC specification (ADBA
https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database
),
and they seem to avoid "JDBC-specific syntax" in favour of
native-for-the-database syntax. However, ADBA is in its early development,
and there are lots of existing applications that use { call my_proc() }
syntax for a good reason.

>IMO JDBC will need to version branch the textual transform of {call} to
"CALL" in v11 and continue with the transform to SELECT in v10 and earlier.

Just one more time: it will break clients who use JDBC's {call ...} syntax
to call functions in v11.
In other words, JDBC specification does not distinguish procedures and
functions, so pgjdbc would have to use either "CALL procedure()" or "SELECT
procedure()" kind of native syntax, however pgjdbc has no clue which one to
use. Current PostgreSQL 11 fails to execute functions via CALL, and it
fails to execute procedures via SELECT.

Of course, application developer can use native syntax directly so
application can use CALL vs SELECT, however that has portability issues
since native syntax is tied to a single DB.
JDBC {call my_proc()} automatically expands to select... for PostgreSQL
and to begin my_proc(); end; in Oracle DB.

Vladimir