"match" (alone) uses fulltext indexing, a completely separate system from what we're doing for the property-specific matching. That indexing only works with whole words (though it handles things like plurals and conjugations I think), which is the expected behavior for search bars, because Google has made that behavior idiomatic. The indexing makes it very fast and provides relevance sorting.

The property-specific stuff uses built-in sql pattern matching. The behavior that we see is the default behavior for pattern matching in that realm. It is relatively easy to start with the default behavior of matching anywhere in the word, and relatively hard to go in the other direction. We can't really duplicate the behavior of the indexed searches in the unindexed searches. Anyhow, we don't really want people building lots of these unindexed searches, because they're slower. Nor do we really have to worry about this yet, since there are so few WQL'ers, particularly nongeeky ones.

Lew and I were talking today about moving away from postgres fulltext and into some more portable indexing libraries. Once we do that, we may be able to do indexed searches for all the options, and then have a separate operator (as you suggest) for more advanced searches.

For now, let's just add an idea for "more consistent matching behavior" and see what comes of the research into the other indexing mechanisms.

  --Ethan McCutchen.....Thu Apr 23 16:53:29 -0700 2009