bug#54591: 29.0.50; sqlite-select returns blob result as multibyte string

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Yuan Fu <casouri@gmail.com>,  54591@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.)