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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 02 Apr 2022 14:59:21 +0200
> Cc: 54591@debbugs.gnu.org
> 
> Let's take a TEXT column first.  Currently, if you have the multibyte
> string "fóo" and insert with "insert into ... (?)", we encode to utf-8
> and put the bytes #x66#xc3#xb3#x6f into the database.  Selecting from
> the database, we get the bytes #x66#xc3#xb3#x6f back, decode and return
> the string "fóo".
> 
> If you have a unibyte string containing the bytes #x66#xc3#xb3#x6f, we
> don't do anything with that, but insert the bytes as is.  When
> selecting, we decode and return "fóo", which is not what the user
> inserted.  In this case, it would be nice to signal an error, but we
> can't, because we don't know that it's a TEXT column in the first place.

We could store unibyte strings as BLOBs, couldn't we?

> Conversely, with BLOB columns, we would prefer to signal an error on
> multibyte strings, but we can't, because we don't know that it's a BLOB
> column.  But we do the right thing with unibyte strings -- if you give
> it #x66#xc3#xb3#x6f, it'll put those bytes into the BLOB column, and
> when selecting, we do know that it's a BLOB column, so we could return
> the unibyte string #x66#xc3#xb3#x6f, and everything's fine.  However, if
> the user wanted to insert the string "fóo", they'll be getting
> #x66#xc3#xb3#x6f back and will probably be sad.

We could refrain from decoding BLOBs, couldn't we?