Au cours des dernières années, je me suis engagé à identifier les atouts et
faiblesses des outils dédiés à la migration vers PostgreSQL. Plusieurs articles
publiés par mes soins ont pavé le chemin vers une direction ambitieuse que
j’entreprends depuis 2024 avec mes collègues Étienne Bersac et
Pierre-Louis Gonon.
… Et la première version stable de PostgreSQL Migrator est sortie le 4
septembre dernier. L’occasion de présenter des fonctionnalités que j’utilise
au quotidien et ce qu’elles apportent par rapport aux autres outils. Dans cet
article, je souhaite m’attarder sur l’une d’entre elles, particulièrement
précieuse pour préparer une migration : le catalogue hors-ligne.
Ces derniers temps, j’ai mis fin à une histoire d’amour avec Debian qui aura
duré près de trois ans. Pas que je n’aime plus le système, oh non, je le préfère
toujours à sa cousine Ubuntu. Mais voilà, j’ai un attachement particulier à
Archlinux depuis, wouh, au moins les bancs de l’école d’ingénieur où nous
l’installions sur des machines virtuelles et où nous nous adonnions à la
pratique du linux ricing pour passer le temps.
Après une expérimentation de Manjaro i3 entre 2019 et 2022 sur mon poste
professionnel, je me suis convaincu qu’il me fallait retourner à l’essentiel. Au
début du mois de septembre, j’ai réussi le portage de ma config Sway de
Debian Trixie vers Archlinux. L’occasion parfaite pour requestionner mes
pratiques en matière de sauvegarde de poste et de remplacer BorgBackup par
Restic.
Au dernier PG Day 2025, j’ai pris la parole pour présenter une méthode de
conception que je juge mature et astucieuse : le partitionnement temporel
avec le type UUID et sa version 7.
Le support de présentation est disponible à cette adresse et je reprendrais
dans cet article, les exemples en guise de démonstration. Je vous propose de
passer en détail ce que j’ai pu y dire, et ne pas y dire faute de temps.
Également, je vous invite à lire ou redécouvrir mes recherches sur le
partitionnement par hachage.
Il est fréquent de vouloir automatiser une tâche répétitive en la scriptant
rapidement, puis à force d’itérations, de l’enrichir, voire de l’intégrer dans
la base de code d’un projet. À ce jeu, les outils comme SQL*Plus et psql peuvent
être de puissants alliés et des interpréteurs aussi pertinents que Bash ou
Python.
Dans le cadre des projets de migration que je mène régulièrement, il m’arrive de
tomber sur ces scripts, en grand nombre. Certains ont la particularité de
proposer des paramètres d’entrée, traités par SQL*Plus avec le mécanisme très
confortable de substitution de variables. Dans cet article, je partage quelques
astuces pour convertir certains aspects de ces scripts grâce aux fonctionnalités
équivalentes que l’on retrouve sur l’outil psql de PostgreSQL.
En tant que pur produit académique des années 2010, mon langage de script de prédilection a
toujours été le Bash (Bourne Again Shell). Non sans ignorer qu’il ait pu en exister d’autres, je
ne me suis jamais vraiment tourné vers d’autres shells pour automatiser les tâches du quotidien
dans mon métier de DBA.
Et pour cause, j’ai administré des centaines de serveurs de distributions très variées et il
n’était pas bien vu d’installer des dépendances systèmes lourdes pour enrichir des scripts Python
ou Perl. Nous apprenions donc à écrire des scripts portables et universels, compatibles partout
où nous déposions nos valises.
Me suis-je enfermé dans un dogme conservateur, en m’interdisant de facto à me tourner vers des
shells modernes et bien plus aisés à appréhender ?