文档是全文搜索系统中的搜索单位，例如一篇杂志文章或一封电子邮件。文本搜索引擎必须能够解析文档，并保存词位（关键字）与其所属文档之间的关联。随后，就可以利用这些关联来搜索包含查询词的文档。

在 PostgreSQL 中进行搜索时，文档通常是数据库表某一行中的一个文本字段，或者是这类字段的组合（串接），这些字段可能分布在多个表里，也可能是动态取得的。换句话说，文档可以由不同部分拼接而成以供索引，而且未必会以一个整体存储在任何地方。例如：

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;

另一种做法是把文档存储为文件系统中的普通文本文件。在这种情况下，数据库可以用于保存全文索引并执行搜索，而文档本身则借助某个唯一标识符从文件系统中取回。不过，从数据库外部检索文件需要超级用户权限或特殊函数支持，因此这种方法通常不如把所有数据都保存在 PostgreSQL 内部方便。此外，把所有内容都放在数据库中，也便于访问文档元数据来辅助索引和展示。

为了进行文本搜索，每个文档都必须被化简为预处理后的 tsvector 格式。搜索和排名完全基于文档的 tsvector 表示来执行 — 只有当文档被选中并准备展示给用户时，才需要取回原始文本。因此，我们常常把 tsvector 直接称作文档，但它当然只是完整文档的一种紧凑表示。

在PostgreSQL中，全文搜索基于匹配操作符@@。如果一个tsvector（文档）匹配一个tsquery（查询），它就返回true。哪一种数据类型写在前面并不重要：

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 操作符把多个术语组合起来。（语法细节见Section 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 不可能在同一位置匹配；但在更复杂的场景中，例如前缀匹配模式，这种形式就可能有用。）

前述的都是简单的文本搜索示例。正如前面所提到的，全文搜索功能包括做更多事情的能力：跳过索引特定词（停用词）、处理同义词并使用更高级的解析，例如基于空白之外的解析。这个功能由文本搜索配置控制。PostgreSQL中有多种语言的预定义配置，并且你可以很容易地创建你自己的配置（psql的\dF命令显示所有可用的配置）。

在安装期间会选择一个合适的配置，并据此在postgresql.conf中设置default_text_search_config。如果整个集簇都使用同一种文本搜索配置，你可以直接使用postgresql.conf中的这个值。若要在整个集簇中使用不同配置，但保证每个数据库内部使用同一种配置，可以使用ALTER DATABASE ... SET。否则，你也可以在每个会话中设置default_text_search_config。

依赖一个配置的每一个文本搜索函数都有一个可选的regconfig参数，因此要使用的配置可以被显式指定。只有当这个参数被忽略时，default_text_search_config才被使用。

为了让建立自定义文本搜索配置更容易，一个配置可以从更简单的数据库对象来建立。PostgreSQL的文本搜索功能提供了四类配置相关的数据库对象：

文本搜索解析器和模板是从低层 C 函数构建而来，因此它要求 C 编程能力来开发新的解析器和模板，并且还需要超级用户权限来把它们安装到一个数据库中（在PostgreSQL发布的contrib/区域中有一些附加的解析器和模板的示例）。由于词典和配置只是对底层解析器和模板的参数化和连接，不需要特殊的权限来创建一个新词典或配置。创建定制词典和配置的示例将在本章稍后的部分给出。