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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html