On Thu, May 1, 2008 at 1:41 AM, Ralf Junker <[EMAIL PROTECTED]> wrote: >>Fair warning, though: It's not entirely clear that the fts search >>syntax should aim to hew too closely to consumer-oriented search >>syntax. > > Interesting point, too. Up to now, I always perceived the FTS search syntax to > be very much consumer-oriented. It it just too similar to major search engines > to be primarily machine-oriented. > > As it stands now, FTS syntax can of course be machine generated, if that is > what you are aiming at. I believe that this should remain easy to do. And my > suggested minus sign modification would not change this, would it?
Right now, things are pretty hybrid. Long-term, one of the design inputs I got from interested parties when we were starting the project is that we probably want to have both a user-oriented syntax and a machine-oriented syntax. Then you could easily just slap something together exposing the fts search syntax, and if you wanted something more precise (perhaps to emulate some other system's query language) you could write your own parser and have a well-defined way to generate queries for fts without having to worry about unexpected syntax changes. You're right that the minus-sign mod probably won't matter one way or the other. I was more addressing the notion that "Google does it that way, fts should too." Matching Google search certainly does have advantages, since people already know how to work it, and Google seems to have done a reasonable job of not injecting all sorts of crazy syntax that nobody can figure out without a quick-reference card. Hmm. I just thought of an interesting notion. You could have a version of fts which takes a very precise query language, then have another virtual table module which wraps that and converts from a looser language to the more precise language. So a certain extent this is make-work, because you'd have to parse, serialize, then re-parse, rather than just generating the query tree directly, but search queries are generally pretty small so it might not matter much (compared to actually executing the query). >>It's sort of in a strange place, most people would think it a >>poor idea (indeed, dangerous!) to put user-entered expressions in >>their WHERE clauses. > > I am not sure I understand the danger. Say I sqlite3_bind() the FTS match > query, do you see this as a serious security risk (FTS injection) or a > potential > performance jeopardy, or something else? There definitely should be no security risks, though there is some potential for performance issues. For instance, a user could ask for a prefix search but your code might run in your UI thread because you only ever tested with exact word matches which were "fast enough". [All of this isn't merely me trying to avoid work. I also polish off such arguments when dealing with some of the biggest users of fts, many of which sit close enough to me to put these questions directly.] -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
