On 18-Jan-10, at 7:38 PM, Markus Hoenicka wrote:

> Markus Hoenicka writes:
>> information. This check simply looks spurious to me:
>> if(field->charsetnr == 63)
> It probably isn't as wrong as I thought initially. MySQL gurus, please
> correct me if I'm wrong, but I take the following from the manual:
> The purpose of the field->charsetnr==63 is to tell TEXT and BLOB
> fields apart (and their relatives of other sizes). Both are
> represented by a FIELD_TYPE_BLOB (or MYSQL_TYPE_BLOB) type. The former
> is a NULL-terminated string with a character set and a collation, the
> latter is a binary object without character set or collation. There is
> apparently no way to tell these apart other than by their
> field->charsetnr value.
> Therefore I tend to think the proper fix is to rearrange the case
> statements in the mysql driver (see the _translate_mysql_type
> function). The VAR_STRING and STRING types should be moved below the
> default: entry to never mark those as binary.

I haven't looked at the code, but that sounds good.

> Vikram, do I understand correctly that you don't expect to be able to
> store binary strings in a "VARCHAR(256) COLLATE 'binary'" column? If
> we fix the driver as I suggested above, you'd get back only the part
> of the string up to the first NULL.

Seems like a quite reasonable expectation when fetching using _string  


> regards,
> Markus

Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
libdbi-users mailing list

Reply via email to