PostgreSQL propose un certain nombre de fonctions qui permettent de calculer des
valeurs agrégées ou relatives sur un ensemble de lignes qui se situent dans une
« fenêtre » autour de la ligne courante. En utilisant de telles fonctions,
n’importe qui peut créer des requêtes plus avancées et plus efficaces pour
l’analyse de leur base de données.
Depuis plusieurs semaines, je contribue à un projet de conversion de modèles de
données vers PostgreSQL, appelé db_migrator. À cette occasion, j’ai
(re)découvert la puissance de ces fonctions de fenêtrage avec le langage
SQL. Dans cet article, je reviens sur un cas concret de transformation des
bornes supérieures d’une table partitionnée en tableau de valeur.
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.