Hi László,

Please note that in 
https://www.sqlite.org/lang_corefunc.html#length

it says that "For a blob value X, length(X) returns the number of bytes
in the blob."

Troy


On Sat, 2020-04-11 at 09:15 +0200, László Böszörményi (GCS) wrote:
> Control: tags -1 +wontfix
> 
> Hi Troy,
> 
> On Thu, Apr 9, 2020 at 6:03 PM Troy Korjuslommi <g...@gyw.com> wrote:
> > The LENGTH() function should return the number of bytes for a
> > column of type BLOB
> > (according to sqlite3 documentation). However, when data is valid
> > UTF-8, it returns the
> > number of characters, not bytes. This means that LENGTH(column) is
> > less than the number of
> > actual bytes returned from SELECT.
>  Please note that I'm the Debian maintainer of the package, not
> affiliated with the SQLite maintainers. They have a forum[1] for such
> discussion and requests.
> This time I know the answer why column data converted unicode string.
> First, length() [2] converts its parameter to a number of characters
> first. You can test it with a number even, see the output of: select
> length(100);
> It will be three as the integer 100 is converted to "100" which is
> three characters wide. But the more generic answer is how datatypes
> are handled in SQLite [3]: "SQLite uses a more general dynamic type
> system. In SQLite, the datatype of a value is associated with the
> value itself, not with its container." In short, it doesn't matter
> that your column type is BLOB - the value of it will be store as is,
> in your case as a unicode string.
> Hence this is expected and it's how SQLite works. Please close this
> bugreport or I plan to do it in some days.
> 
> Regards,
> Laszlo/GCS
> [1] https://sqlite.org/forum/forummain
> [2] https://www.sqlite.org/lang_corefunc.html#length
> [3] https://www.sqlite.org/datatype3.html

Reply via email to