Alors que la version 15 de PostgreSQL se prépare à sortir dans les prochains
jours, le groupe de développement du projet communautaire ont intégré leurs
récents travaux pour accélérer les tâches d’automatisation et de compilation
à l’aide du système de construction Meson.
Ce chantier n’est pas anodin et redessine les contours de l’écosystème du moteur
de bases de données open-source le plus avancé au monde. Depuis sa forme libre
publiée en 1998, PostgreSQL repose sur des solutions robustes et éprouvées, mais
de plus en plus complexes à maintenir pour les nouvelles générations de
contributeur·rices. En proposant de se tourner vers un logiciel comme Meson, ces
amoureux et amoureuses du libre se tournent résolument vers l’avenir.
L’étape d’analyse crée un arbre d’analyse qui n’utilise que les règles fixes
de la structure syntaxique de SQL. Il ne fait aucune recherche dans les
catalogues système. Il n’y a donc aucune possibilité de comprendre la sémantique
détaillée des opérations demandées.
Que se passe-t-il entre l’instant où une requête SQL est soumise par l’utilisateur
et l’envoi du résultat sous forme de lignes par le serveur PostgreSQL ? Cette
question passionnante (pour une poignée de personnes, ne nous le cachons pas) a
été étudiée par Stefan Simkovics durant sa thèse pour l’université de
technologie de Vienne en 1998.
Ces travaux ont notamment permis d’enrichir la documentation officielle avec
le chapitre « Présentation des mécanismes internes de PostgreSQL », qui reprend
assez largement les observations de Simkovics de manière simplifiée pour en
faciliter l’accès au plus grand nombre.
Dans cet article, je souhaite présenter de récentes découvertes sur l’une de ces
phases internes, l’étape d’analyse, qui permet de manipuler une requête SQL sous
une forme d’arbre et qui respecte un pattern de développement avancé nommé AST
(abstract syntax tree).
Pour garantir la qualité du code d’un logiciel, rien de mieux que la validation
par les tests. Ces derniers peuvent être de différentes natures (fonctionnels,
intégration, unitaires, performance, etc.) et permettent de respecter une série
d’exigences que s’imposent les développeurs pour maintenir et faire évoluer ledit
logiciel dans la bonne direction.
Dans cet article, je souhaite explorer le système de tests tel qu’il est (et
a été) implémenté dans PostgreSQL et comment le réemployer dans la rédaction d’une
extension communautaire. Si vous ne connaissiez pas l’outil pg_regress, il
n’aura plus de secret pour vous !
À l’image d’un langage de programmation classique, le SQL manipule des données
typées, comme les chaînes de caractères, les dates ou des entiers numériques.
Les opérations de transformations ou de comparaison diffèrent en fonction du
type de données ; il ne sera pas possible de comparer le caractère A avec le
chiffre 4 mais l’opérateur || permettra la concaténation des deux éléments.
Dans cet article, je souhaite partager quelques anecdotes et problématiques de
terrain concernant cette particularité logicielle et comprendre les effets de
bord pour mieux les appréhender. Je prendrais un exemple assez spécifique du type
oid et d’un risque de transtypage pouvant perturber le stockage de Large
Objects dans une table, voire leur destruction non désirée.
Le marché de la migration en France est intense. Le Groupe de Travail
Inter-Entreprises PostgreSQL (PGGTIE) a même publié un guide de transition
à PostgreSQL à destination des entreprises françaises. Ce dernier est le fruit
de près de cinq années de travaux au sein de plusieurs organismes publics et a
pour ambition de démontrer l’intérêt de PostgreSQL aux décideurs techniques en
présentant les forces et les faiblesses du moteur.
Le mois dernier, une traduction en anglais est sortie des cartons pour
promouvoir davantage ce mouvement vers le logiciel libre dans les autres pays.
Je trouvais intéressant de profiter de cette actualité pour partager mes
réflexions du moment, entre ma vision du marché français et l’approche technique
pour engager les migrations de données vers PostgreSQL.