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 ?
Bien que la norme SQL définisse un ensemble de règles pour que les systèmes de bases
de données puissent être interchangeables, il existe de petites singularités dans la
nature. À ce titre, le type de données hierarchyid fourni par SQL Server est un
exemple flagrant. Si vous êtes amené à basculer vers PostgreSQL, deux solutions s’offrent
à vous.
Une première et plus simple consiste à lier chaque nœud à son parent à l’aide d’une nouvelle
colonne parentid et d’y appliquer une contrainte de clé étrangère. Une autre approche,
plus complète, consiste à utiliser l’extension ltree. Cet article traite de ce dernier
cas.
Le PG Day France s’est tenu les 11 et 12 juin derniers à Lille, ma ville natale.
Il s’agit de l’événement de la communauté française de PostgreSQL qui pose ses valises dans une
ville différente chaque année. L’occasion était trop belle pour moi et j’y ai rencontré de nombreuses
personnes venant de toute la France et de ses alentours, pour discuter de PostgreSQL au cours
de deux jours d’ateliers et de conférences.
Pour cette édition, j’ai eu le plaisir de prendre la parole et de faire un retour d’expérience
sur l’animation du groupe Meetup local dont j’ai repris les rennes il y a maintenant quatre ans.
Dans cet article, je souhaite retranscrire les principaux points abordés lors de cette présentation,
en attendant que la vidéo de la conférence soit mise en ligne.
Lors de la dernière PGSession 16, j’ai rédigé et animé un atelier de
trois heures au sujet de la migration vers PostgreSQL à l’aide des Foreign Data
Wrappers, ou FDW. Ce fut notamment l’occasion de présenter au grand public,
l’extension db_migrator pour laquelle j’ai dédié un article sur ce
blog.
Au cours de cet atelier, nous pouvons constater que la copie des données avec
l’extension db_migrator n’est pas parfaitement prise en charge. En effet, bien
qu’il existe une fonction de bas niveau pour répartir sur plusieurs processus le
transfert table à table, de nombreuses situations devront exiger de rédiger un
grand nombre de requêtes SQL pour se tirer d’affaire. Au cours des mois qui
suivirent, je me suis attelé à la conception d’un assistant écrit en
PL/pgSQL dont le but est de simplifier la génération de ces requêtes.