Not everyone who uses the sqlite docs is a 1337 c guru. Most of them are probably rubyists, pythonistas, some php script kiddies, and, as of late, android and ios devs (some of which are a bit more leet).
Monkey see, monkey do. If I see output in comments, I expect the same output when I run the code. It wasn't clear to me, it's obviously very clear to you. I think the docs could be better, more eye-catching on the important points: -- NOTE: blobs print as empty strings in the sqlite3 cli, if you want to see debug output use hex(). -- NOTE: this isn't what the output you see looks like, it's been hand-formatted for easy-reading But y'all do whatcha gon' do. AJ ONeal On Sat, Jul 21, 2012 at 6:22 PM, Pavel Ivanov <paiva...@gmail.com> wrote: > On Sat, Jul 21, 2012 at 7:35 PM, AJ ONeal <coola...@gmail.com> wrote: > >> > >> Read the documentation carefully: > >> http://www.sqlite.org/fts3.html#matchinfo. Right the first paragraph: > >> > >> The matchinfo function returns a blob value. If it is used within a > >> query that does not use the full-text index (a "query by rowid" or > >> "linear scan"), then the blob is zero bytes in size. Otherwise, the > >> blob consists of zero or more 32-bit unsigned integers in machine > >> byte-order. > >> > >> What part of this paragraph makes you believe that if you print the > >> result of matchinfo as text you will see something meaningful? > >> > > > > The part where it shows output in the comments of the example that, > > according to common conventions used in documentation, would indicate it > is > > the output of the function (which it is, just not the user-viewable > output). > > Where did you see that? Could you cite it? All I see is > > -- ... If each block of 4 bytes in the blob is interpreted > -- as an unsigned integer in machine byte-order, the values will be: > -- > -- 3 2 1 3 2 0 1 1 1 2 2 0 1 1 0 0 0 1 1 1 > > So it's clearly says: you have to interpret it, it's not like you just > print it as string. > > > Plenty of languages (javascript, ruby, python, etc, etc, etc) > pretty-print > > native objects when they are to be represented as text. > > > > What about that paragraph indicates that the sqlite3 cli doesn't know how > > to pretty-print understand its own native types? > > sqlite3 cli understand its native type which is BLOB. But how should > it pretty-print it? BLOB can contain absolutely any information and > it's not its job to parse SQL to try to understand what this blob can > actually contain. > > > Pavel > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
