Как предотвратить полнотекстовый поиск парсера PostgreSQL, переписывая символы в пробелы?

Question

Моя проблема заключается в том, что парсер PL/pgSQL рассматривает символы типа «#» или «+» как пробельные символы (это ОК), поэтому запросы, подобные «C++» или «C#» или «PL/SQL», анализируются следующим образом:

asciiword | Word, all ASCII | C  | {english_stem}  | english_stem | {c} 
blank  | Space symbols | #  | {thesaurus_en,simple} | simple  | {#} 

Я пытаюсь найти лучший способ справиться с такими запросами. Я пытался это сделать, используя словарь тезауруса, но не похоже, что он может работать.

Что я имею в виду, это то, что переписывает «C#» на «CSHARP» во время записи в базу данных (поскольку я предполагаю, что «C#» будет индексироваться как «C») и что-то, что будет делать то же самое при поиске ,

Я мог бы сделать это на стороне моего веб-приложения, но это просто не кажется правильным.

Как я мог бы справиться с тем или каким триггерам PL/pgSQL я мог бы использовать для подхода, о котором я думаю?

Answer 1

Ну, вы могли бы написать свой собственный парсер (на C), но это, вероятно, больше усилий, чем вы хотели.

Вы могли бы сделать что-то вроде:

to_tsvector('english', my_transformer(document_text)) 
... 
to_tsquery('english', my_transformer(query_text)) 

Вам не нужно, чтобы преобразовать фактический буквальный текст документа, только индекс и поисковый вектора запрос. Вы можете сделать это и в определении индекса (но my_transformer должен быть неизменной функцией).

Вопрос тогда становится тем, что самый простой/эффективный способ преобразования входящего текста. Если вы уже используете plperl/pltcl, вы, вероятно, можете сделать какую-нибудь умную замену регулярным выражением. Если нет, попробуйте несколько простых регулярных выражений в plpgsql или даже plsql. Всегда есть неудобные угловые случаи с такой штукой, поэтому убедитесь, что вы тщательно протестировали свои замены.

Answer 2

(. Сообщение от имени ОП)

На будущее, есть большое руководство по созданию полнотекстовый парсер здесь: http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/docs/HOWTO-parser-tsearch2.html

Во всяком случае, решение, предложенное Ричардом прекрасно работает и требуется гораздо меньше усилий.