It looks like a bug.

Try the follwing code with DBD::SQLite2 (previous version), and it will show the correct result.

use strict;
use warnings;
use Data::Dumper;
use DBI;

my $dbh = DBI->connect('DBI:SQLite2:dbname=test_blob.db', '', '');

$dbh->{sqlite_handle_binary_nulls}=1;

$dbh->do('CREATE TABLE test_blob( Bindata BLOB )');

my $bindata = "ABC" . "\x00" . "DEFINITIVELY";

print Data::Dumper->Dump([$bindata],['original']);
my $sth1 = $dbh->prepare('INSERT INTO test_blob VALUES(?)' );
$sth1->execute($bindata);

my $sth2 = $dbh->prepare('SELECT Bindata FROM test_blob');
$sth2->execute();

my $row = $sth2->fetch();
my $fetched_data = $row->[0];

print Data::Dumper->Dump([$fetched_data],['fetched']);
[download]

Results:

$original = 'ABCDEFINITIVELY';
$fetched = 'ABCDEFINITIVELY';

Moreover, the data was inserted even using SQLite 3.

If you want to be sure, just check if the file contains the string you have inserted after char 0x0.

$ grep DEFINITIVELY test_blob.db
Binary file test_blob.db matches
[download]

Therefore, the bug is in the retrieval function. (Notice that the standalone sqlite3 binary program gets the same truncated result.)