Simon Slavin wrote:
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 --
On Fri, Nov 11, 2011 at 11:55 AM, Yuriy Kaminskiy yum...@mail.ru wrote:
One way or other, =, LIKE and GLOB results should be consistent.
If string is NUL-terminated, = should ignore everything after NUL.
If string is length-terminated, LIKE should not ignore bytes after NUL.
blob = blob should
On 11 Nov 2011, at 6:09pm, Nico Williams wrote:
blob = blob should be a binary comparison
blob = string should be a string comparison
blob LIKE pattern should either treat the blob as a string or not, but
I don't see why either behavior should imply that blob = blob should
be anything
On Fri, Nov 11, 2011 at 1:16 PM, Simon Slavin slav...@bigfraud.org wrote:
On 11 Nov 2011, at 6:09pm, Nico Williams wrote:
blob = blob should be a binary comparison
blob = string should be a string comparison
blob LIKE pattern should either treat the blob as a string or not, but
I don't see
Paul Corke wrote:
On 09 November 2011 15:32, hmas wrote:
sqlite select hex(foocol) from footable where foocol like
'98012470700566';
39393939393830313234373037303035363600
It looks like there's an extra 00 on the end.
x'3900' != x'39'
That said, it seems LIKE operator is buggy.
On 11/09/11 19:42, Yuriy Kaminskiy wrote:
Paul Corke wrote:
On 09 November 2011 15:32, hmas wrote:
sqlite select hex(foocol) from footable where foocol like
'98012470700566';
39393939393830313234373037303035363600
It looks like there's an extra 00 on the end.
x'3900' != x'39'
That
Roger Andersson wrote:
On 11/09/11 19:42, Yuriy Kaminskiy wrote:
Paul Corke wrote:
On 09 November 2011 15:32, hmas wrote:
sqlite select hex(foocol) from footable where foocol like
'98012470700566';
39393939393830313234373037303035363600
It looks like there's an extra 00 on the end.
