On 9 Nov 2011, at 8:03pm, Yuriy Kaminskiy wrote: > Look at: > SELECT hex(X'1245005679'),hex(X'1245001234'); > > And compare: > SELECT X'1245005679' LIKE X'1245001234'; > 1 -- incorrect > SELECT X'1245005679' = X'1245001234'; > 0 -- correct > SELECT X'1245005679' > X'1245001234'; > 1 -- correct > > "LIKE" (in both "native" and "icu" implementations) ignores value length > (sqlite_value_bytes) and stops at NUL character. Compare that with "=" and ">" > that compares full value. > > Arguable SQL_BLOB should be illegal operand for LIKE/GLOB, but then this > should > be documented and they should return error when called with BLOB argument > instead of returning nonsense.
The definition of LIKE on the expression page states (not with complete clarity) that LIKE operates on strings. So we're back to an old favourite: a decision as to what constitutes a string inside SQLite. One definition would say that a string would terminate with the first 0x00 no matter how many bytes are stored (C style strings). Another would say that the string terminates with the last byte stored (Pascal style strings). I don't think any official definition is stated anywhere in the documentation intended for users. (I haven't looked at comments in the source code.) And I suspect that if DRH wants to decide one way or another, this may point up some inconsistencies in the codebase which should be quickly fixed. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
