Roman Rokytskyy wrote:

> Jim,
>
>
>> Text search needs to be multi-table and multi-field to be useful.
>>
>
> I guess, you did not change your approach to this topic significantly,
> right? Then your multi-table search can be used only via API and
> result of such query is set of result sets, which cannot be
> represented via SQL.
>

Yes, that's correct. The result of a search operation is a ResultList
that can be iterated similar to a ResultSet, but the "value" of a
ResultList is a ResultSet rather than a scalar value.

> But MySQL as well as your Netfrastructure provide a keyword that
> allowed to perform a query against single table (and they are not the
> only ones - Oracle and MS SQL do similar things). Do you want to say
> that MATCH/MATCHING operators and alike is not useful at all?
>

I have a customer who is quite happy using the MATCHING predicate
against a single column. The implementation is a general search
constrained to a single table and column. The semantics are otherwise
the same.

The Falcon search code will be part of the initial Falcon alpha code
base even though it isn't accessible through MySQL. Like other MySQL
code, it will be released under the GPL, but the ideas will be there for
the taking. MySQL has an existing full text search capability that I
would prefer not to comment on publicly.

> I'd say that suggested keyword search is a simplified version of MATCH
> operator that accesses a multi-field FTS index, however only for one
> table. Having that case implemented would be of great benefit for
> Firebird, considering amount of applications that use FTS via SQL.
> Don't you agree?
>

Personally, I believe that web style applications are better
applications that the traditional File/Edit/View framework, and web
application begin with search. There are good uses for a heavily
restrictive search, however. In my book, implementing a multi-table,
multi-field index then, if appropriate, filtering at the node walking
level to a single table and field makes a great deal of sense.