MySQL Bugs: #56507: Need API to return a SQL BINARY column from ResultSet

Bug #56507	Need API to return a SQL BINARY column from ResultSet
Submitted:	2 Sep 2010 16:53	Modified:	9 Sep 2010 1:18
Reporter:	peter kwong	Email Updates:
Status:	Open	Impact on me:	None
Category:	Connector / C++	Severity:	S4 (Feature request)
Version:	1.0.5	OS:	Linux
Assigned to:	Assigned Account	CPU Architecture:	Any

Description:
The ResultSet class does not have a getBinary() or similar API to return
a table column that is defined as a BINARY (eg. BINARY(16)).

In Java, the getBinary() returns a ByteArray, I believe.

How to repeat:
Look in ResultSet class definition.

Suggested fix:
Add a method to return a BINARY column from a ResultSet.

Do you mean something similar to JDBC's getBinaryStream(), http://download.oracle.com/javase/1.4.2/docs/api/java/sql/ResultSet.html#getBinaryStream(i...) ?

I looked through the JDBC doc for java again 

http://download.oracle.com/javase/6/docs/api/index.html

and see the getBytes() which is closer to what I was looking for.

I wanted to store a 16-byte number (UUID) into the database as BINARY(16)
and wanted a way to retrieve those 16-bytes.

I think getString should work for you. You can access all bytes via c_str() from 0 to length()-1 byte. length() is supposed to return full field data length, and not as for the null terminated string.

If I use getString, version 1.0.5 of Connector/C++ returns a std:string type.
Wouldn't the c_str() method for the string class return all bytes up to the
NULL ('\0') terminator? If the binary data (say BINARY (16)) 
I am storing does not have a 
null terminator, would the c_str() still return just 16 bytes? 

What if the binary data has a zero byte somewhere in it, would the c_str()
function still return all 16 bytes?

I'm not so sure getString()would handle binary data correctly.

should be always 16 bytes. at least before you perform any operations on the string that might require to recalculate the length. it's easy to try.

Tried the getString() followed by extracting each byte up the length() bytes.
It does work as you explained, although it isn't very intuitive.

A getBytes() API would be more intuitive and is in line with JDBC's API.

I agree it's not intuitive. we will consider introducing geBytes or smth else.