| PostgreSQL 9.3.2文書 | ||||
|---|---|---|---|---|
| 前のページ | 上に戻る | 付録 F. 追加で提供されるモジュール | 次のページ | |
tsearch2モジュールは、テキスト検索がリリース8.3でコアPostgreSQLに統合される前の、tsearch2を使用したアプリケーション向けの後方互換のテキスト検索機能を提供します。
組み込みのテキスト検索機能は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モジュールは別名演算子をまったく定義しません。 完全に組み込みのものに依存しています。 まったく一般的ではありませんが、アプリケーションが明示的にスキーマ修飾した演算子名を使用する場合のみ、問題が発生します。
tsearch2を使用した、8.3より前のインストレーションからの推奨更新方法を以下に示します。
通常の方法で古いインストレーションのダンプを作成します。 ただし、pg_dumpまたはpg_dumpallの-c (--clean)オプションは使用しないでください。
新しいインストレーションで、空のデータベースを作成し、置き換え版のtsearch2をテキスト検索を使用する各データベースにインストールしてください。 これをダンプデータをロードする前に行う必要があります。 古いインストレーションがpublic以外のスキーマにtsearch2のオブジェクトを持つ場合は、置き換え版のオブジェクトが同じスキーマ内に生成されるようにCREATE EXTENSIONコマンドを確実に調整してください。
ダンプデータをロードしてください。 実際、元のtsearch2のオブジェクトの再作成に失敗するため、いくつかエラーが報告されます。 これらのエラーは無視することができますが、単一トランザクションでダンプをリストアすることができないことを意味します。 （例えば、pg_restoreの-1スイッチを使用することはできません。）
リストアしたtsearch2の設定テーブル（pg_ts_cfgなど）の内容を検査してください。 そして、必要に応じて同等の組込みテキスト検索設定を作成してください。 古い設定テーブルから有用な情報をすべて取り出した後、これらを削除することができます。
アプリケーションを試験します。
後で、最終的に置き換え版のtsearch2モジュールをアンインストールできるように、アプリケーション内の別名テキスト検索オブジェクトへの参照の名前を変更する方がよいでしょう。