David>JDBC driver or similar drivers to use the CALL command always from
PG11 on, then the meaning of {call f1(a, b)} will have changed and a
Note: technically speaking, JDBC has two flavours of syntax (however standard does not clarify the distinction):
S1) {? := call my_proc(?,?) }
S2) { call my_proc(?, ?) }
Theoretically speaking, we could presume that S1 is for calling functions while S2 is for calling procedures.
However, does not looks like a way out since
1) It does not provide a way to call void returning functions. Users might have lots of void-returning functions since procedures were missing.
2) Other languages might happen to have single syntax only. For instance, CommandType in .NET seems to be in (StoredProcedure, TableDirect, Text). There's no room for procedure vs function.
Peter>JDBC driver or similar drivers to use the CALL command always from
Peter>PG11 on, then the meaning of {call f1(a, b)} will have changed and a
Peter>lot of things will break in dangerous ways.
PG10 did not have procedures, so only "functions" could theoretically break.
If CALL can be used to call functions, and the drivers could play their way to make the result-set look like before, then no breakage happens.
Note: driver does not blindly rewrite {call f1(a,b)} to call f1(a,b). It does send prepare/describe/etc/etc messages. At the end of the day, the purpose of having a DB driver is to have a consistent API that works across DB versions/DB products.
David>Not implementing this optimization in pg11 but supporting functions via call is something I could live with.
+1
Vladimir