Un outil hors ligne qui isole les incompatibilités avant migration

pgrecon se distingue par son approche entièrement hors ligne : il ne se connecte jamais aux bases de données source (Oracle) ou cible (PostgreSQL), selon la source officielle de PostgreSQL. L'outil commence par un script SQLPlus en lecture seule, qui génère une extraction révisable des schémas Oracle. Cette extraction sert de base à un moteur de règles déterministe appliquant 80 critères couvrant les types de données, la sémantique de longueur (comme la conversion de VARCHAR2(30 CHAR) en varchar(30)), les partitions, les constructions PL/SQL, ou encore les performances. Le résultat est du DDL PostgreSQL natif pour les tables, contraintes, index, vues (y compris les hiérarchies CONNECT BY converties en WITH RECURSIVE), vues matérialisées, commentaires, permissions, déclencheurs simples et routines autonomes.

Un outil qui émet silencieusement une estimation approximative pour chaque cas complexe affichera toujours une liste de refus plus courte que celle de pgrecon.

Un rapport de résidus pour anticiper le travail manuel

Contrairement à d'autres outils qui masquent les incompatibilités, pgrecon adopte une transparence radicale : tout élément non convertible fidèlement est listé dans un rapport de résidus, avec son nom et la raison du blocage, comme les vues utilisant JSON_TABLE (nécessitant une réécriture manuelle selon les différences entre PostgreSQL 17 et les versions antérieures), les déclencheurs composés (à restructurer en déclencheurs séparés), ou les colonnes utilisant des localisateurs de fichiers externes (sans équivalent direct dans PostgreSQL), selon un article technique sur dev.to. Ce rapport est conçu pour fournir une estimation précise du travail manuel à prévoir, évitant ainsi les surprises en cours de migration. Par exemple, les packages Oracle (comme Alexandria) ou les vues triant par XMLTYPE sont systématiquement exclus de la conversion automatique.

Des tests rigoureux pour garantir la fiabilité des conversions

La robustesse de pgrecon repose sur des tests automatisés poussés. Les pipelines CI vérifient l'extraction contre plusieurs versions d'Oracle (XE 11g, XE 21c, Free 23ai) et appliquent la sortie convertie sur PostgreSQL 16 et 17 (PostgreSQL 18 est mentionné comme testé mais sans précision sur son support officiel). Un fuzzer de schéma génère chaque nuit 40 schémas Oracle aléatoires pour s'assurer qu'aucun crash ou perte silencieuse ne survient, selon les détails techniques partagés par PostgreSQL. Le benchmark public, basé sur les schémas HR, OE et CO d'Oracle ainsi que sur des packages comme utPLSQL ou PLJSON, valide la conversion de 423 statements sans rejet à la version 0.7.3. Ces tests couvrent aussi les sémantiques de longueur (caractères vs octets) et les objets comme les séquences ou les déclencheurs DML simples.

Ce que cela change ici : une migration maîtrisée pour les entreprises et administrations

Pour les entreprises et administrations béninoises ou d'Afrique de l'Ouest utilisant des bases Oracle et souhaitant migrer vers PostgreSQL, pgrecon offre un cadre pour évaluer la faisabilité technique avant engagement. Son rapport de résidus permet d'identifier précisément les composants nécessitant une refonte manuelle, évitant ainsi des coûts cachés. Par exemple, une administration utilisant des vues hiérarchiques complexes (CONNECT BY) ou des déclencheurs autonomes pourrait estimer le temps et les ressources nécessaires pour les adapter. De même, les entreprises dépendantes de packages Oracle (comme ceux pour la gestion des logs) pourraient prioriser leur migration en fonction de leur criticité. L'outil, disponible via pip install pgrecon, se positionne comme un préliminaire indispensable pour les migrations critiques, où la compatibilité et la traçabilité des incompatibilités sont prioritaires.