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.
Regards, Andrew.
--
_____________________________________________________________________ Andrew McMillan, e-mail:
Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267