Tom, Thanks for the quick reply. Doing a frontend mapping was my next option since I really don't care about / and the ability to search on it. Preventing the parser from using the file tokenizer seemed like a better solution so I wanted to go down that path first (there are other false hits i was worried about too, like email, etc) I'm really confused about what "ALTER TEXT SEARCH CONFIGURATION dict DROP MAPPING FOR file" actually does. The documentation seems to make it sound like it does what I want, but I guess it does something else. --brian On Jul 28, 2010, at 2:06 PM, Tom Lane wrote: > Brian Hirt <bhirt@xxxxxxxxxxxxx> writes: >> For example instead of the parser recognizing three asciiword it recognizes one asciiword and one file. I'd like a way to have the / just get parsed as blank. > > AFAIK the only good way to do that is to write your own parser :-(. > The builtin parser isn't really configurable. (If you didn't mind > maintaining a private version you could patch its state transition > table manually, but that seems like a PITA.) > > For the case at hand it could be a pretty thin frontend to the builtin > text parser --- just change / to space and then call the builtin one. > contrib/test_parser/ might help you get started. > > regards, tom lane > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
