Re: Full text indexing (Question/request)

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