As recently discovered there is more than one reason why an intelligent driver, like the JDBC standard at least requires in a few instances, requires knowledge of at least some basic structure
of the statements it sees before sending them off to the server.
Indeed.
For one thing, PgJDBC needs to be able to parse the passed SQL text to extract individual statements and split up multi-statements server-side so it can bind/parse/execute them separately.
It also has to be able to find placeholders in the query.... and not be confused by what might be placeholders if not contained within "identifier quoting", 'literal quoting' or $q$dollar quoting$q$.
I see almost zero utility in teaching the server about client-side abstractions like {? = call } . Half the *point* of those is that the *driver* is supposed to understand them and turn them into *DBMS-specific* syntax. They're escapes.
Furthermore, and particularly in the JDBC example you provide, my first reaction is that it would be a massive encapsulation violation to try and get PostgreSQL to understand "{? = call funcname(args)}" and similar higher level API specifications.
+10
Even if it were easy, it'd be an awful idea. It'd also introduce huge ambiguities as the mess of umpteen different client parameter-specifier formats, procedure-call escape formats, etc all clashed in a hideous and confused mess.
This is the client's job. If the client wants to use %(whatever)s, ?, $1, :paramname, or Σparam☑ as parameter placeholders we shouldn't have to care. Same with call-escapes etc. So long as we provide a sensible, well defined way to do what the client driver needs to do to implement what its clients expect.
Now, I do think we should one day have a proper CALL statement, but that's for top-level true stored procedures and unrelated to how the client talks to the client driver.
