Postgres Pro Enterprise
9.6
Postgres Pro Standard
9.69.5
PostgreSQL
9.69.59.4
RUENRU EN
Документация по PostgreSQL 9.4.1
Пред.Уровень вышеПриложение E. Дополнительно поставляемые модулиСлед.

E.42. tsearch2

Модуль tsearch2 предоставляет функциональность текстового поиска для обратной совместимости с приложениями, которые использовали tsearch2 до того, как текстовый поиск был интегрирован в ядро PostgreSQL в версии 8.3.

E.42.1. Вопросы переносимости

Хотя встроенные функции текстового поиска были основаны на функциях tsearch2 и во многом похожи, есть ряд небольших различий, из-за которых возникают вопросы переносимости с существующими приложениями:

  • Были изменены имена некоторых функций, например функция rank стала ts_rank. Модуль замены tsearch2 предоставляет псевдонимы для старых имён.

  • Все типы данных и функции встроенного текстового поиска существуют в системной схеме pg_catalog. При установке из tsearch2 эти объекты обычно помещались в схему public, хотя некоторые пользователи могли поместить их в специальную отдельную схему. Таким образом, ссылки на объекты, дополненные схемой, окажутся нерабочими в любом случае. Модуль замены tsearch2 предоставляет для этих объектов псевдонимы, которые помещаются в схему public (или другую, если это требуется), чтобы такие ссылки продолжали работать.

  • Для встроенных функций текстового поиска отсутствуют понятия "текущий анализатор" и "текущий словарь", есть только текущая конфигурация поиска (она задаётся параметром default_text_search_config). Хотя текущий анализатор и текущий словарь использовались раньше только функциями, предназначенными для отладки, это всё же может мешать переносимости в некоторых случаях. Модуль замены tsearch2 имитирует эти дополнительные переменные состояния и предоставляет обратно-совместимые функции, позволяющие задать и прочитать их.

Есть ряд проблем, решения которых не предлагает модуль tsearch2, так что код приложения придётся корректировать в любом случае:

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

  • Информация о конфигурации текстового поиска была перенесена в системные каталоги, которые значительно отличаются от таблиц аналогичного предназначения в tsearch2. Все приложения, анализирующие или модифицирующие эти таблицы, нуждаются в корректировке.

  • Ели приложение использует какие-либо нестандартные конфигурации текстового поиска, их нужно будет настроить в системных каталогах, применив новые SQL-команды конфигурирования текстового поиска. Модуль замены tsearch2 предлагает небольшую помощь в этом, позволяя загружать старый набор конфигурационных таблиц tsearch2 в PostgreSQL 8.3. (Без этого модуля загрузить данные конфигурации невозможно, так как значения в колонках regprocedure нельзя сопоставить с функциями.) Эти таблицы конфигурации на самом деле не будут ничего делать, но их содержимое будет полезно хотя бы для того, чтобы получить аналогичную конфигурацию в 8.3.

  • Старые функции reset_tsearch() и get_covers() не поддерживаются.

  • Модуль замены tsearch2 не определяет никакие псевдонимы операторов, полностью рассчитывая на встроенные. Это может вызвать проблемы, если в приложении использовались имена операторов с явным указанием схемы, что встречается очень редко.

E.42.2. Преобразование инсталляции версии до 8.3

Обновлять инсталляцию версии до 8.3, в которой использовалось расширение tsearch2, рекомендуется следующим образом:

  1. Выгрузите данные старой инсталляции обычным способом, не используя ключ -c (--clean) программы pg_dump или pg_dumpall.

  2. В новой инсталляции создайте пустые базы данных и установите модуль замены tsearch2 в каждую базу, где будет использоваться текстовый поиск. Это нужно сделать до загрузки данных в базу! Если в старой инсталляции объекты tsearch2 содержались в схеме, отличной от public, обязательно отразите это в команде CREATE EXTENSION, чтобы заменяющие объекты создавались в той же схеме.

  3. Загрузите выгруженные данные. При этом могут возникнуть ошибки из-за невозможности воссоздать первоначальные объекты tsearch2. Хотя их можно игнорировать, это значит, что вы не сможете восстановить выгруженные данные в одной транзакции (то есть, нельзя использовать ключ -1 команды pg_restore).

  4. Изучите содержимое восстановленных конфигурационных таблиц tsearch2 (pg_ts_cfg и т. д.) и создайте аналогичные конфигурации текстового поиска по потребности. Получив из старых конфигурационных таблиц всю полезную информацию, вы можете удалить их.

  5. Протестируйте работу приложения.

Позже вы можете поменять ссылки в приложении на псевдонимы объектов текстового поиска, что позволит в конце концов удалить модуль замены tsearch2.

E.42.3. Ссылки

Сайт разработки Tsearch2 http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/

Пред.НачалоСлед.
test_shm_mqУровень вышеunaccent
PostgreSQL 9.4.1 Documentation
PrevUpAppendix F. Additional Supplied ModulesNext

F.42. tsearch2

The tsearch2 module provides backwards-compatible text search functionality for applications that used tsearch2 before text searching was integrated into core PostgreSQL in release 8.3.

F.42.1. Portability Issues

Although the built-in text search features were based on tsearch2 and are largely similar to it, there are numerous small differences that will create portability issues for existing applications:

  • Some functions' names were changed, for example rank to ts_rank. The replacement tsearch2 module provides aliases having the old names.

  • The built-in text search data types and functions all exist within the system schema pg_catalog. In an installation using tsearch2, these objects would usually have been in the public schema, though some users chose to place them in a separate schema of their own. Explicitly schema-qualified references to the objects will therefore fail in either case. The replacement tsearch2 module provides alias objects that are stored in public (or another schema if necessary) so that such references will still work.

  • There is no concept of a "current parser" or "current dictionary" in the built-in text search features, only of a current search configuration (set by the default_text_search_config parameter). While the current parser and current dictionary were used only by functions intended for debugging, this might still pose a porting obstacle in some cases. The replacement tsearch2 module emulates these additional state variables and provides backwards-compatible functions for setting and retrieving them.

There are some issues that are not addressed by the replacement tsearch2 module, and will therefore require application code changes in any case:

  • The old tsearch2 trigger function allowed items in its argument list to be names of functions to be invoked on the text data before it was converted to tsvector format. This was removed as being a security hole, since it was not possible to guarantee that the function invoked was the one intended. The recommended approach if the data must be massaged before being indexed is to write a custom trigger that does the work for itself.

  • Text search configuration information has been moved into core system catalogs that are noticeably different from the tables used by tsearch2. Any applications that examined or modified those tables will need adjustment.

  • If an application used any custom text search configurations, those will need to be set up in the core catalogs using the new text search configuration SQL commands. The replacement tsearch2 module offers a little bit of support for this by making it possible to load an old set of tsearch2 configuration tables into PostgreSQL 8.3. (Without the module, it is not possible to load the configuration data because values in the regprocedure columns cannot be resolved to functions.) While those configuration tables won't actually do anything, at least their contents will be available to be consulted while setting up an equivalent custom configuration in 8.3.

  • The old reset_tsearch() and get_covers() functions are not supported.

  • The replacement tsearch2 module does not define any alias operators, relying entirely on the built-in ones. This would only pose an issue if an application used explicitly schema-qualified operator names, which is very uncommon.

F.42.2. Converting a pre-8.3 Installation

The recommended way to update a pre-8.3 installation that uses tsearch2 is:

  1. Make a dump from the old installation in the usual way, but be sure not to use -c (--clean) option of pg_dump or pg_dumpall.

  2. In the new installation, create empty database(s) and install the replacement tsearch2 module into each database that will use text search. This must be done before loading the dump data! If your old installation had the tsearch2 objects in a schema other than public, be sure to adjust the CREATE EXTENSION command so that the replacement objects are created in that same schema.

  3. Load the dump data. There will be quite a few errors reported due to failure to recreate the original tsearch2 objects. These errors can be ignored, but this means you cannot restore the dump in a single transaction (eg, you cannot use pg_restore's -1 switch).

  4. Examine the contents of the restored tsearch2 configuration tables (pg_ts_cfg and so on), and create equivalent built-in text search configurations as needed. You may drop the old configuration tables once you've extracted all the useful information from them.

  5. Test your application.

At a later time you may wish to rename application references to the alias text search objects, so that you can eventually uninstall the replacement tsearch2 module.

F.42.3. References

Tsearch2 Development Site http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/

PrevHomeNext
test_shm_mqUpunaccent
FAQ