>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.
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