Andrew McMillan wrote:
>
> Bruce Momjian wrote:
> >
> > See contrib/fulltextindex.
>
> An easy answer, but not a very good solution in the real world.
>
> contrib/fulltextindex requires you to jump through hoops in developing
> queries to retrieve your data. It's also very space-inefficient in that
> a table with a fulltextindex on a field needs another table with a
> complete set of values for that field, as well as any substrings of that
> field, and then it wants two indexes on that table. Add that up!
>
> It would be nice to see a true index which was full text. It would be
> nice to see a true index which allowed an individual field to index to
> many entries through a function interface. This would straightforwardly
> allow people to create their own simple functions to perform full-text,
> keyword or other indexing schemes quite simply.
>
> It naively appears to me that the function interface is moving closer to
> achieving this with the enhancements in 7.1 to the use of setof()
> returns combined with the earlier enhancement to indexing on function
> results.
>
> If a function fulltextindex(text) returned a setof() the substrings in
> its text argument, how hard will it be to index on that return value and
> allow WHERE field=fulltextindex('substring') to use that index?
>
> Of course such a fulltextindex() function would have to know not to do
> any processing on the string when called in the second situation. Is it
> possible for functions to do this sort of trick? It seems a bit beyond
> the pale!
>
> I would _love_ to see full-text or keyword indexing natively in
> PostgreSQL.
I tottally agree with you. FTI is not a good solution. It seems natural
that PostgreSQL will have a built-in (and better) FTI, now that the
TOAST project will be implemented in 7.1.
Poul L. Christiansen