Hi Florian,
> > The most recent patches were submitted by me, so I guess you
> could call me
> > the defacto "maintainer".
>
> Okay - glad someone answered me :)
Actually, I replied to you 5 minutes after you posted, but I think my emails
were being stalled somewhere...
> I will - please give me a few days for an up to date documentation
> concerning the changed and new features.
>
> And yes - I really appreciate your offer for code review!
To generate the diff, do this:
cd contrib/fulltextindex
cvs diff -c > ftidiff.txt
Then email -hackers the ftidiff.txt.
> > > 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 there is - I couldn't find it. I did find a lot of frustated
> posts about
> isalpha and locale-awareness although.
Yeah, I can't find anything in the man pages either. Maybe we can ask the
list. People?
> > List: what should we do about the backward compatibility problem?
>
> I think the only reasonable way for keeping backward compatibiliy might be
> to leave the old fti function alone and introduce a new one with
> the changes
> (e.g. ftia). Even another fti parameter which activates the new features
> breaks the compatibility concerning the call. Activiation via DEFINE is
> another option, but this requires messing around with the source code
> (although very little) on the user side. Maybe a ./configure option is a
> good way (but this is beyond my C and friends skills).
I think that creating a new function, called ftia or ftix or something is
the best solution. I think I can handle doing that...
Chris