Open NattyNarwhal opened 1 year ago
This feature is extremely important. I've seen this behaviour in production, where I just wanted to fetch a BLOB on and IBMi via PDO/ODBC and an hex string was returned (sometimes even with a weird truncation behaviour). Resorted to using straight ODBC interface to more idiomatically fetch the binary.
Description
As part of supporting multiple users, I've found that they have difficulty with dealing with binary columns with PDO drivers.
SQL_C_CHAR
shaped bindings on binary columns versus binding it as a binary on the C side. (Specifically, it would hex-encode the column. Useful perhaps, but unexpected for the user.)odbc_result
work by accident by binding it as a binary on the C side, even though I don;'t think the procedural ODBC binding interface can represent that.Notably, these aren't necessarily LOBs - they can be (relatively) small, users don't (want to) deal with them in terms of streams on the PHP side (as PHP strings can represent binary data just fine), etc. Treating them as strings isn't right, because they can be subject to unwanted and inappropriate encoding conversions or an inefficient representation over the wire.
Proposal
Extend the PDO constants to have a
PARAM_BINARY
binding type, and use it in drivers. For things like ODBC (where I'm most familiar), this would map to anSQL_C_BINARY
binding type, with the equivalent in other drivers when possible.User code could look something like:
Basically looks like using
PARAM_STR
, and would maintain a string interface unlikePARAM_LOB
.Possible problems/alternatives
I'm not committed to the proposed interface; I just know there is a problem dealing with binaries. If there's another way to solve this, I'd like to hear it.
PARAM_STR_NATL
orPARAM_STR_INTL
could be set on aPARAM_STR
, so why notPARAM_STR_BINARY
?PARAM_STMT
has even sketchier support (specifically, it's in none of them) and is also a constant, so there is precedent for types not supported by all drivers.PARAM_LOB
: The intent of a LOB is somewhat similar, but with different semantics. Also note a LOB doesn't necessarily have to be binary data (blob), it can be a large string (clob), and (var)binary columns aren't blobs anyways. GH-10343 overrides the semantics ofPARAM_LOB
for binary non-stream content, but I'm not sure if this is appropriate.PARAM_STR
: For the TDS case, the driver could automatically detect binary data, but the semantics issue exposed by i.e. ODBC remains.