無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

F.39. tsearch2

tsearch2 モジュールは、テキスト検索がリリース8.3でコア PostgreSQL に統合される前の、 tsearch2 を使用したアプリケーション向けの後方互換のテキスト検索機能を提供します。

F.39.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 モジュールは別名演算子をまったく定義しません。 完全に組み込みのものに依存しています。 まったく一般的ではありませんが、アプリケーションが明示的にスキーマ修飾した演算子名を使用する場合のみ、問題が発生します。

F.39.2. 8.3より前のインストレーションを変換

tsearch2 を使用した、8.3より前のインストレーションからの推奨更新方法を以下に示します。

  1. 通常の方法で古いインストレーションのダンプを作成します。 ただし、 pg_dump または pg_dumpall -c ( --clean )オプションは使用しないでください。

  2. 新しいインストレーションで、空のデータベースを作成し、置き換え版の tsearch2 をテキスト検索を使用する各データベースにインストールしてください。 これをダンプデータをロードする 前に 行う必要があります。 古いインストレーションが public 以外のスキーマに tsearch2 のオブジェクトを持つ場合は、置き換え版のオブジェクトが同じスキーマ内に生成されるように CREATE EXTENSION コマンドを確実に調整してください。

  3. ダンプデータをロードしてください。 実際、元の tsearch2 のオブジェクトの再作成に失敗するため、いくつかエラーが報告されます。 これらのエラーは無視することができますが、単一トランザクションでダンプをリストアすることができないことを意味します。 (例えば、 pg_restore -1 スイッチを使用することはできません。)

  4. リストアした tsearch2 の設定テーブル( pg_ts_cfg など)の内容を検査してください。 そして、必要に応じて同等の組込みテキスト検索設定を作成してください。 古い設定テーブルから有用な情報をすべて取り出した後、これらを削除することができます。

  5. アプリケーションを試験します。

後で、最終的に置き換え版の tsearch2 モジュールをアンインストールできるように、アプリケーション内の別名テキスト検索オブジェクトへの参照の名前を変更する方がよいでしょう。


powered by SEO.CUG.NET