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

Previous Next

Full log

Message #41 received at 54591 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54591 <at> debbugs.gnu.org, fjas <at> grdm.no
Subject: Re: bug#54591: 29.0.50;
 sqlite-select returns blob result as multibyte string
Date: Sat, 02 Apr 2022 16:51:51 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 02 Apr 2022 14:59:21 +0200
> Cc: 54591 <at> 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?

Previous Next

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