GNU bug report logs - #54591
29.0.50; sqlite-select returns blob result as multibyte string

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54591 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: bug#54591: 29.0.50; sqlite-select returns blob result as multibyte string
Date: Tue, 29 Mar 2022 18:38:59 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Yuan Fu <casouri <at> gmail.com>,  54591 <at> debbugs.gnu.org
> Date: Tue, 29 Mar 2022 16:38:43 +0200
> 
> > If we want to support non-text data in a blob, then yes, I think you
> > are right.
> 
> I'm not sure there's any way to do that reliably.  If we change blob
> selections to not decode, then if you have
> 
> create table if not exists test7 (col1 text, col2 blob)
> 
> and then
> 
> (format "insert into test7 values ('foó', '%s')" binary)
> 
> will have to encode the entire string in utf-8, meaning you get garbage
> back when you select.  (While today you get encoded binary back.)
> 
> And if just say "well, don't do that, then; use prepared statements",
> then
> 
> "insert into test7 values (?, ?)" ["foo" binary]
> 
> could work...  if we knew the type of the columns here, but I can't find
> any way to determine that on a statement that has been executed yet
> (sqlite3_column_type/sqlite3_column_decltype only seems to work on
> selects; perhaps I'm missing something -- anybody know?)

Can we place the burden of knowing the type of the column on the
caller?  I mean, if they know it's a binary blob, they should tell us,
and then we don't decode it?

(Of course, if there's a way of knowing the type, we could DTRT
automatically for each type.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.