This is the last post I will make about my text search system, I'll
respond off line if anyone wants to correspond. I have taken up too much
bandwidth as it is. The only reason I have been so persistent is that I
can't believe that I am the only person having this particular problem,
and that some resolution will make Postgres an even better product. I am
posting this so people trying to do what I have been trying to do, have
someplace to start. ;-)
Resolution:
Short of creating a new index type in Postgres, and waiting for some
later version which allows "sets" to be returned by functions, we are
left with few options. My best solution, as kludgy as it is, is this:
select search_exec('bla bla');
create temp table fubar as select search_key() as "key", search_rank()
as "rank" from search_template where search_advance()>0 limit count;
select * from table where some_table.key = fubar.key;
Assumptions:
search_template is a table which contains [n] number of rows of one or
more fields. [n] is some maximum number of results. search_template
should be sufficiently small to be as efficient as possible. A valid
table must be used because multiple results need to be returned.
<HACKERS>
If the postgres hackers want to make a 'virtual table' called something
like "pg_counter" which, when queried, returns an enumeration starting
with '0'..'[n]' that would be cool. The danger, of course, is that a
limit must be specified, but it could be useful beyond just my
application
</HACKERS>
Aside from this hack, I have been unable to find a reasonably expedient
way to do this. I have this working on a system, and it does seem to
work. If anyone has a reasonable alternative, or knows of any problems
this approach may have, I'd love to hear it. If anyone is interested in
the interface code, I would be glad to supply it as GPL.
I am very grateful for all the attention and patience.
Mark.
--
http://www.mohawksoft.com
