Changes in /contrib/fulltextindex

Hi Florian,

I have done some changes and improvements to the fulltextindex trigger
(contrib/fulltextindex). As these changes affects among other things the
parameter list I would like to ask the maintainer about his thoughts

before

I submit a patch. And there comes the problem - there is no explizit
maintainer listed in the accompanying docs. The last changes according to
the cvs log has been done by Bruce Momjian.

The most recent patches were submitted by me, so I guess you could call me
the defacto "maintainer".

Maybe the original author is subscribed to this list and can get in touch
with me because I'm kind of new to incorporation patches to a open source
project.

Cool, reply to me personally if you need technical help, or if you want me
to review your patch and use the list to discuss things that affect the
project...

The changes made include:

+ Changed the split up behaviour from checking via isalpha to
using a list of delimiters as isalpha is a pain used with
data containing german umlauts, etc. ATM this list contains:

" ,;.:-_#/*+~^�!?\"\\�$%&()[]{}=<>|0123456789\n\r\t@�"

Good idea. Is there a locale-aware version of isalpha anywhere?

+ If the do be indexed field has'nt changed, the indexing will
not be done. This way unnecessary redindexing of fields not
affected by an update can by omited.

Fantastic! That was on my list of things to do!

+ There is a new field 'word' of type BOOL in the index table.
Using this field, it is possible to do 'full word' and
'substring' searches.

Hehe - that was another idea I had as well. Breaks back compatibility.

+ The text gets no longer lowercased before it is written into
the index table. This way it is possible to to casesensitive
and incasesenstive (via a functional index using lower) searches.

ok

+ Added functionality to prevent indexing of duplicate words
(this is one item of the todo list in fti.c) using a hash
table. As this is chained to a significant loos of performance
and depends on the indexed data, this can be turned on or off
via a newly introduced parameter.

ok.

OK Florian, can you please send me your new contrib/fulltextindex directory
tarred up?

List: what should we do about the backward compatibility problem?

Chris

Christopher Kings-Lynne wrote:

+ There is a new field 'word' of type BOOL in the index table.
Using this field, it is possible to do 'full word' and
'substring' searches.

Hehe - that was another idea I had as well. Breaks back compatibility.
ok.

OK Florian, can you please send me your new contrib/fulltextindex directory
tarred up?

Or a 'diff -c' against 7.2.X.

List: what should we do about the backward compatibility problem?

I don't see a problem with backward compatbility here. It is contrib,
and the README has to explain that they need to reinstall. I will
mention that in 7.3 HISTORY.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

+ There is a new field 'word' of type BOOL in the index table.
Using this field, it is possible to do 'full word' and
'substring' searches.

Hehe - that was another idea I had as well. Breaks back compatibility.

List: what should we do about the backward compatibility problem?

I'd be inclined to grin and bear it, if it only extends to needing to
rebuild the supporting index. Changing the name of the function that
an application needs to call will be a much bigger pain than that, no?

regards, tom lane