| PostgreSQL 9.6.0 手册 | |||
|---|---|---|---|
| 上一页 | 上一级 | 附录 F. 额外提供的模块 | 下一页 |
F.41. tsearch2
tsearch2模块为使用旧版本tsearch2（文本搜索在 8.3 时才被整合到核心PostgreSQL）的应用提供了向后兼容的文本搜索功能。
F.41.1. 移植性问题
尽管内建的文本搜索特性是基于tsearch2的并且与它在很大程度上相似，仍然有一些区别会导致已有应用中的移植性问题：
-
一些函数名被更改，例如
rank被改成了ts_rank。替代的tsearch2模块提供了具有旧名称的别名。 -
内建的文本搜索数据类型以及函数全部存在于系统模式pg_catalog中。在一个使用tsearch2的安装中，这些对象通常在public模式中，不过一些用户选择将它们放置在自己拥有的一个单独的模式中。因此在任何一种情况下，显式地通过模式限定来引用这些对象将会失败。替代的tsearch2模块提供存储在public（或者另一个模式）中的别名对象，这样上面的引用就还能工作。
-
在内建的文本搜索特性中没有"当前解析器"或者"当前字典"的概念，只有当前搜索配置的概念（通过default_text_search_config参数设置）。而当前解析器和当前字典只用于调试目的的函数，这在一些情况下会形成一种移植障碍。替代的tsearch2模块模拟了这些额外的状态变量并且提供了向后兼容的函数来设置和检索它们。
有一些问题在替代的tsearch2模块中并未被说明，并且因此将要求修改应用的代码：
-
旧的
tsearch2触发器函数允许其参数列表中的项是文本数据被转换成tsvector格式之前在其上调用的函数名。它已经被作为一种安全性漏洞被移除，因为无法保证被调用的函数就是想要调用的那一个。如果数据在被索引前必须被处理，推荐的方法是写一个自定义触发器来完成该工作。 -
文本搜索配置信息被移动到核心系统目录中，它们和tsearch2使用的表有显著的不同。任何检查或者修改这些表的应用将需要被调整。
-
如果一个应用使用了任意自定义文本搜索配置，该配置都需要使用新的文本搜索配置 SQL 命令在核心目录中进行设置。替代的tsearch2模块谓词提供了一点支持，允许把一个老的 配置表载入到PostgreSQL 8.3 中（如果没有这个模块，就没有办法载入配置数据因为regprocedure列中的值不能被解析成函数）。虽然那些配置表实际上并不真正做什么事情，至少在 8.3 中建立一个等效的自定义配置时可以参考它们的内容。
-
老的
reset_tsearch()和get_covers()函数不再被支持。 -
替代的tsearch2模块没有定义任何别名操作符，完全依赖于内建的操作符。如果一个应用使用了显式模式限定的操作符名，这会产生问题，不过这种情况非常少见。
F.41.2. 转换一个 8.3 之前的安装
更新一个使用tsearch2的 8.3 之前的安装的推荐方法是：
-
使用通常的方法从旧安装制作一个转储，但是确保不要使用pg_dump或pg_dumpall的-c（--clean）选项。
-
在新安装中，创建空数据库并且在每一个将使用文本搜索的数据库中安装替代的tsearch2模块。这必须在载入转储数据之前完成。如果旧的安装在public之外的一个模式中放有tsearch2对象，确保调整CREATE EXTENSION命令这样替代的对象会被创建在同一个模式中。
-
载入转出数据。这将会报告不少错误，因为无法重新创建原来的tsearch2对象。这些错误可以被忽略，但是这意味着你无法在一个单一事务中恢复转储（例如，你不能使用pg_restore的-1开关）。
-
检查恢复后的tsearch2配置表的内容（pg_ts_cfg等等），并且根据需要创建等效的内建文本搜索配置。一旦已经从旧的配置表中抽取了所有有用的信息，你就可以删除掉旧的配置表了。
-
测试你的应用。
在晚些时候，你可能希望把应用引用重命名成别名文本搜索对象，这样你可以最终卸载替代的tsearch2模块。