Документ является единицей поиска в системе полнотекстового поиска; например, статья в журнале или электронное письмо. Поисковый движок должен уметь анализировать документы и сохранять связи лексем (ключевых слов) с их родительским документом. Позже эти связи используются для поиска документов, содержащих запрашиваемые слова.

Для поиска внутри Tantor BE, документ обычно представляет собой текстовое поле в строке таблицы базы данных, или, возможно, комбинацию (конкатенацию) таких полей, возможно, хранящихся в нескольких таблицах или полученных динамически. Другими словами, документ может быть создан из разных частей для индексации и он может не быть храниться где-либо в целом. Например:

SELECT title || ' ' ||  author || ' ' ||  abstract || ' ' || body AS document
FROM messages
WHERE mid = 12;

SELECT m.title || ' ' || m.author || ' ' || m.abstract || ' ' || d.body AS document
FROM messages m, docs d
WHERE m.mid = d.did AND m.mid = 12;

Еще одна возможность - хранить документы в виде простых текстовых файлов в файловой системе. В этом случае база данных может использоваться для хранения полнотекстового индекса и выполнения поисковых запросов, а для получения документа из файловой системы может использоваться некий уникальный идентификатор. Однако, для получения файлов извне базы данных требуются привилегии суперпользователя или поддержка специальных функций, поэтому это обычно менее удобно, чем хранение всех данных внутри Tantor BE. Кроме того, хранение всего внутри базы данных обеспечивает легкий доступ к метаданным документа для помощи в индексации и отображении.

Для целей текстового поиска каждый документ должен быть преобразован в предварительно обработанный формат tsvector. Поиск и ранжирование выполняются полностью на основе представления документа в виде tsvector - исходный текст нужно извлекать только тогда, когда документ был выбран для отображения пользователю. Поэтому мы часто говорим о tsvector как о документе, но, конечно же, это только компактное представление полного документа.

Полнотекстовый поиск в Tantor BEоснован на операторе сравнения @@, который возвращает true, если tsvector (документ) соответствует tsquery (запросу). Неважно, какой тип данных указан первым.

SELECT 'a fat cat sat on a mat and ate a fat rat'::tsvector @@ 'cat & rat'::tsquery;
 ?column?
----------
 t

SELECT 'fat & cow'::tsquery @@ 'a fat cat sat on a mat and ate a fat rat'::tsvector;
 ?column?
----------
 f

Как и предыдущий пример подразумевает, tsquery - это не просто сырой текст, так же как и tsvector. tsquery содержит поисковые термины, которые должны быть уже нормализованными лексемами и могут объединять несколько терминов с помощью операторов AND, OR, NOT и FOLLOWED BY. (Подробности синтаксиса см. в Раздел 8.11.2). Существуют функции to_tsquery, plainto_tsquery и phraseto_tsquery, которые помогают преобразовывать текст, написанный пользователем, в правильный tsquery, в основном путем нормализации слов, появляющихся в тексте. Аналогично, to_tsvector используется для разбора и нормализации строки документа. Таким образом, на практике поиск по тексту будет выглядеть примерно так:

SELECT to_tsvector('fat cats ate fat rats') @@ to_tsquery('fat & rat');
 ?column?
----------
 t

Обратите внимание, что это совпадение не будет успешным, если записано как

SELECT 'fat cats ate fat rats'::tsvector @@ to_tsquery('fat & rat');
 ?column?
----------
 f

поскольку здесь не будет нормализации слова rats, элементы tsvector представляют собой лексемы, которые предполагаются уже нормализованными, поэтому rats не соответствует rat.

Оператор @@ также поддерживает ввод типа text, позволяя пропустить явное преобразование текстовой строки в типы tsvector или tsquery в простых случаях. Доступны следующие варианты:

tsvector @@ tsquery
tsquery  @@ tsvector
text @@ tsquery
text @@ text

Первые два из них мы уже видели. Форма text @@ tsquery эквивалентна to_tsvector(x) @@ y. Форма text @@ text эквивалентна to_tsvector(x) @@ plainto_tsquery(y).

Внутри tsquery оператор & (AND) указывает, что оба его аргумента должны присутствовать в документе для совпадения. Аналогично, оператор | (OR) указывает, что должен присутствовать хотя бы один из его аргументов, в то время как оператор ! (NOT) указывает, что его аргумент должен не присутствовать для совпадения. Например, запрос fat & ! rat совпадает с документами, содержащими слово fat, но не содержащими слово rat.

Поиск фраз возможен с помощью оператора <-> (FOLLOWED BY) типа tsquery, который сопоставляется только в том случае, если его аргументы имеют совпадения, которые являются смежными и в заданном порядке. Например:

SELECT to_tsvector('fatal error') @@ to_tsquery('fatal <-> error');
 ?column?
----------
 t

SELECT to_tsvector('error is not fatal') @@ to_tsquery('fatal <-> error');
 ?column?
----------
 f

Существует более общая версия оператора FOLLOWED BY, имеющая форму <N>, где N - целое число, указывающее разницу между позициями совпадающих лексем. <1> эквивалентно <->, в то время как <2> позволяет появление ровно одной другой лексемы между совпадениями, и так далее. Функция phraseto_tsquery использует этот оператор для создания tsquery, который может сопоставляться с многословной фразой, когда некоторые из слов являются стоп-словами. Например:

SELECT phraseto_tsquery('cats ate rats');
       phraseto_tsquery
-------------------------------
 'cat' <-> 'ate' <-> 'rat'

SELECT phraseto_tsquery('the cats ate the rats');
       phraseto_tsquery
-------------------------------
 'cat' <-> 'ate' <2> 'rat'

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

Скобки могут использоваться для управления вложенностью операторов tsquery. Без скобок, оператор | имеет наименьший приоритет, затем &, затем <->, и ! имеет наивысший приоритет.

Стоит отметить, что операторы AND/OR/NOT имеют несколько иное значение, когда они находятся в аргументах оператора FOLLOWED BY, чем когда они находятся вне его, потому что внутри FOLLOWED BY точное положение совпадения имеет значение. Например, обычно !x соответствует только документам, не содержащим x в любом месте. Но !x <-> y соответствует y, если он не находится сразу после x; наличие x в другом месте документа не препятствует совпадению. Еще один пример: x & y обычно требует, чтобы x и y появлялись где-то в документе, но (x & y) <-> z требует, чтобы x и y совпадали в одном месте, непосредственно перед z. Таким образом, этот запрос ведет себя иначе, чем x <-> z & y <-> z, который будет соответствовать документу, содержащему две отдельные последовательности x z и y z. (Этот конкретный запрос бесполезен в текущей форме, так как x и y не могут совпадать в одном месте; но с более сложными ситуациями, такими как шаблоны с префиксным совпадением, запрос такой формы может быть полезен).

Вышеуказанные примеры являются простыми примерами текстового поиска. Как уже упоминалось ранее, функциональность полнотекстового поиска включает возможность выполнения множества других действий: пропуск индексации определенных слов (стоп-слов), обработка синонимов и использование сложного анализа, например, анализ на основе не только пробелов. Эта функциональность контролируется конфигурациями полнотекстового поиска. Tantor BE поставляется с предопределенными конфигурациями для многих языков, и вы можете легко создать свои собственные конфигурации. (Команда \dF в psql показывает все доступные конфигурации).

Во время установки выбирается соответствующая конфигурация, и default_text_search_config устанавливается соответственно в файле postgresql.conf. Если вы используете одну и ту же конфигурацию полнотекстового поиска для всего кластера, вы можете использовать значение в файле postgresql.conf. Чтобы использовать разные конфигурации во всем кластере, но одну и ту же конфигурацию в каждой базе данных, используйте ALTER DATABASE ... SET. В противном случае, вы можете установить default_text_search_config в каждой сессии.

Каждая функция текстового поиска, которая зависит от конфигурации, имеет необязательный аргумент regconfig, чтобы конфигурацию можно было указать явно. default_text_search_config используется только в том случае, если этот аргумент не указан.

Для упрощения создания настраиваемых конфигураций текстового поиска, конфигурация составляется из более простых объектов базы данных. Средство текстового поиска Tantor BE предоставляет четыре типа объектов базы данных, связанных с конфигурацией:

Парсеры и шаблоны текстового поиска создаются на основе низкоуровневых функций на языке C; поэтому для разработки новых требуется знание языка C, а для установки в базу данных — привилегии суперпользователя. (В дистрибутиве Tantor BE в каталоге contrib/ содержатся примеры дополнительных парсеров и шаблонов). Так как словари и конфигурации являются параметризованными и связывающими элементами некоторых базовых парсеров и шаблонов, для создания нового словаря или конфигурации не требуется особых привилегий. Примеры создания пользовательских словарей и конфигураций приведены позже в этой главе.