sharedkv: avoid ambiguity for numeric-like string keys

While we only store URLs and binary SHA-1/SHA-256 values in skv
at the moment, we may store potentially ambiguous keys/values in
the future.  It's possible to store "02" and have it treated as
`2' unless explicitly binding parameters as SQL_BLOB.  This
behavior was independent of the sqlite_unicode parameter as
evidenced by the new tests.

I only noticed this bug while hacking on another project using
DBD::SQLite, and not while hacking on public-inbox itself.

1 files changed, 3 insertions, 0 deletions

diff --git a/t/shared_kv.t b/t/shared_kv.t
index 8b4f9c29..8dfd3b25 100644
--- a/t/shared_kv.t
+++ b/t/shared_kv.t
@@ -42,5 +42,8 @@ undef $skv;
 ok(!-d $skv_tmpdir, 'temporary dir gone');
 $skv = PublicInbox::SharedKV->new("$tmpdir/dir", 'base');
 ok(-e "$tmpdir/dir/base.sqlite3", 'file created');
+$skv->dbh;
+ok($skv->set_maybe('02', '2'), "`02' set");
+ok($skv->set_maybe('2', '2'), "`2' set (no match on `02')");
 
 done_testing;