Documentation PostgreSQL 9.5.25 > Annexes > Modules supplémentaires fournis > tsearch2 | |
test_decoding | tsm_system_rows |
Le module tsearch2 fournit une compatibilité ascendante pour la fonctionnalité de recherche plein texte avec les applications qui ont utilisé tsearch2 avant que la recherche plein texte ne soit intégré au cœur de PostgreSQL™ dans la version 8.3.
Bien que les fonctionnalités de recherche plein texte intégrées au moteur sont basées sur tsearch2 et sont largement similaires à ce dernier, il existe un grand nombre de petites différences qui créent des problèmes de portabilités pour les applications existantes :
Certains noms de fonctions ont été changés, par exemple rank en ts_rank. Le remplacement du module tsearch2 fournit des alias utilisant les anciens noms.
Les types de données et les fonctions de recherche existent tous dans le schéma système pg_catalog. Dans une installation utilisant tsearch2, ces objets auraient été créé dans le schéma public bien que certains utilisateurs ont choisi de les placer dans un schéma propre. Les références explicites de schéma échoueront donc dans tous les cas. Le remplacement du module tsearch2 fournit des objets qui sont stockés dans public (ou un autre schéma si nécessaire) pour que les références en question fonctionnent.
Le concept d'« analyseur courant » et de « dictionnaire courant » n'existe pas dans les fonctionnalités intégrées. Seule la configuration courante est disponible (via le paramètre default_text_search_config). Bien que l'analyseur courant et le dictionnaire courant étaient seulement utilisés par les fonctions de déboguage, ceci pourrait être un obstacle de portage dans certains cas. Le module de remplacement tsearch2 émule ces variables d'état et fournit des fonctions de compatibilité ascendante pour leur initialisation et leur récupération.
Il existe des problèmes qui ne sont pas adressés par le module de remplacement tsearch2, ce qui réclamera des modifications dans le code des applications :
L'ancienne fonction trigger tsearch2 permettait l'utilisation d'une liste d'arguments indiquant le nom des fonctions à appeler sur la donnée de type texte avant la conversion au format tsvector. Ceci a été supprimé car c'est une faille de sécurité. Il n'était pas possible de garantir que la fonction appelée était celle qui était voulue. L'approche recommendée si la donnée doit être traitée avant d'être indexée est d'écrire un trigger personnalisé qui fait le boulot lui-même.
Les informations sur la configuration de la recherche plein texte ont été déplacées dans les catalogues système qui sont vraiment différents des tables utilisées par tsearch2. Toutes applications qui examinent ou modifient ces tables ont besoin d'être modifiées.
Si une application a utilisé des configurations personnalisées de recherche plein texte, ces dernières devront être revues pour être placées dans les catalogues système en utilisant les nouvelles commandes SQL de configuration de la recherche plein texte. Le module de remplacement tsearch2 offre un peu de support pour cela en permettant le chargement des anciennes tables de configuration de tsearch2 avec PostgreSQL™ 8.3. (Sans ce module, il n'est pas possible de charger les données de configuration car les valeurs des colonnes regprocedure ne peuvent utiliser des fonctions.) Bien que ces tables de configuration ne font vraiment rien, au moins leur contenu sera disponible à la consultation lors de la configuration d'une configuration personnalisée dans 8.3.
Les anciennes fonctions reset_tsearch() et get_covers() ne sont pas supportées.
Le module de remplacement tsearch2 ne définit pas d'alias d'opérateurs, se reposant entièrement sur les opérateurs internes. Ceci pose un problème seulement si une application utilise les noms d'opérateurs en les qualifiant du schéma, ce qui est très rare.
La façon recommandée de mettre à jour une installation pré-8.3 qui utilise tsearch2 est :
Faire une sauvegarde de l'ancienne installation de la façon habituelle, mais en s'assurant de ne pas utiliser l'option -c (option --clean)de pg_dump et pg_dumpall.
Dans la nouvelle installation, créez une ou plusieurs bases de donnée vides et installez le module de remplacement tsearch2 dans chaque base qui utilise la recherche plein texte. Ceci doit être fait avant le chargement des données ! Si votre ancienne installation a placé les objets de tsearch2 dans un autre schéma que public, assurez-vous d'ajuster la commande CREATE EXTENSION pour que les objets de remplacement soient créés dans ce même schéma.
Rechargez la sauvegarde. Il y aura quelques erreurs dûes à la restauration impossible d'objets du tsearch2 original. Ces erreurs peuvent être ignorées mais cela signifie que vous ne pouvez pas restaurer la sauvegarde dans une transaction complète (autrement dit, vous ne pouvez pas utiliser l'option -1 de pg_restore).
Examinez le contenu des tables de configuration restaurées de tsearch2 (pg_ts_cfg et ainsi de suite), et créez les configurations internes de recherche plein texte nécessaire. Vous pouvez supprimer les anciennes tables de configuration une fois que vous avez extrait toutes les informations utiles.
Testez votre application.
Plus tard, si vous le souhaitez, vous pourrez renommer les références de l'application aux alias des objets internes pour que vous puissez éventuellement déinstaller le module de remplacement tsearch2.