On Tue, Jan 22, 2008 at 4:32 PM, Andy Goth <[EMAIL PROTECTED]> wrote: > On Tue, 22 Jan 2008 14:19:10 -0800, Scott Hess wrote > > Hmm. I think the current behaviour is because the obvious result for > > this query would be the set of all documents with the documents > > matching each of the negated terms removed. > > I disagree that this is the obvious result. Searching for empty string > yields > no results, so adding a constraint on top of that should also yield no > results. But if searching for empty string yielded all rows, I would agree > with you that it is the obvious result.
MATCH "foo -bar" should return "The set of documents which match foo but not bar". I read MATCH "-bar" as "The set of all documents which do not match bar". MATCH "-foo -bar" would be "The set of all documents which do not match foo and do not match bar". I'm not sure how the empty-string results matter, as I don't consider MATCH "-foo" to have an implicit empty term. > > In the current system, calculating the set of all documents isn't > > convenient, so since this couldn't be supported, it's an error. > > Then how does "select * from my_fts3_table" work? That's what I'm saying. Calculating the set of all documents which match "foo" and the set of all documents which match "bar" and removing the latter from the former is conveniently available from the fts index. Calculating the set of all documents in the fts index would require running a separate query to figure it out. In absolute terms, that would actually be a simpler thing to implement, but since the code to get the matches for a particular term already exists, and the code to get the complete set of documents doesn't, getting the complete set is relatively more complicated. -scott ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
