Proxy mechanism to support converting bind marker about r2dbc-proxy HOT 2 CLOSED

Thanks for picking up on this loose end. JDBC users want probably a conversion of ? to $1/@P1. We have also another aspect that plays into that which is stream parameter reuse:

conn.createStatement("INSERT INTO names (first_name, last_name) VALUES (:PARAM:, :PARAM:) ")
    .bind(":PARAM:", Blob.from(…))
    .execute()

In this case, native execution accepts a single blob and translates it into the right result. Bind marker conversion would likely try to consume the Blob twice if we go for identifiable bind markers. Anonymous bind markers (such as ?) require users to specify individual items because they correlate by positional occurence.

from r2dbc-proxy.

With current converter API, above bind operation can be translated like this in converter.

Blob blob = Blob.from(...);
stmt.bind("$0", blob);
stmt.bind("$1", blob);

So, single stmt.bind(":PARAM:", Blob.from(…)) can be converted to multiple bind operations - stmt.bind("$0", blob).bind("$1", blob).

Or, even query can be translated to INSERT INTO names (first_name, last_name) VALUES ($0,$0) and bind operation can perform stmt.bind("$0", Blob.from(...)) if driver/database allow such query and operation.

There is interesting aspect in multiple parameter expansion (as above example) with Blob(or Clob).
As you mentioned, I think the Blob will be consumed twice. So, this wouldn't work if blob is not able to support multiple read. If driver supports such that blob can be reused in different parameter binding (when same Blob object is passed in different bind operation), then it would work.

At this converter level, it is still manipulating SPI.
So, after all, it's pretty much on the driver that how much support it has, and the implementation of this converter API transforms the user defined binding operations to the extent that driver can understand by performing pass-through, skip, or modifying originated bind operations.

from r2dbc-proxy.