On Thu, Aug 28, 2008 at 8:15 PM, Andreas Ntaflos <[EMAIL PROTECTED]> wrote: > Notice the snippet bit: it takes the virtual table name (fts_paper in the case > of your examples) instead of the column name as an argument, which I find > curious. Your query would fail with the following error message: > > SQL error: illegal first argument to html_snippet
The snippet thing is because fts needs to pass a bit of magic between the results of the MATCH and the snippet function. At creation, fts3 adds a hidden column with the same name as the table, and then it feeds the bit of magic out through that. There's no way SQLite proper can see this, and fts3 has no way to see the table aliases (the snippet implementation sees the value passed, not the name of the value passed). snippet() can only operate off of the results of the MATCH, so specifying the column could be ambiguous (what if you passed a column which didn't participate in the MATCH?). So, in the examples you gave, b.paper_text will be passing in the TEXT from that column in the row, and snippet() doesn't have the info it needs to operate. Passing b doesn't work, because b is a table, and you cannot pass tables to functions. fts_paper is passing the magic hidden column, NOT the table named fts_paper, it could also be written b.fts_paper. I almost wonder if it wouldn't make sense to add an additional hidden column called match, and maybe another called all. Then you could write things like: SELECT docid, snippet(match) FROM fts_table WHERE all MATCH 'foo'; SELECT t.docid, snippet(t.match) FROM fts_table AS t WHERE t.all MATCH 'foo'; I think that would be less surprising to people, because using a table-named column is ambiguous. When it works, it looks like you managed to use the table name, but when it doesn't, it just makes it harder to figure out what really _is_ going on. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
