La norme ISO SQL/Foundation (ISO/IEC 9075-2:2016) fait partie du standard
SQL et définit les règles pour la définition des relations et la manipulation
des données. En adoptant cette norme, les moteurs de bases de données
garantissent une interopérabilité avec leurs concurrents et permettent aux
entreprises de bénéficier d’une plus grande flexibilité lorsqu’elles souhaitent
passer de l’un à l’autre sans (trop) réécrire leur modèle de données ou leurs
requêtes SQL.
Dans sa publication SQL:2003, la norme a introduit le concept de colonnes
générées comme nouvelle spécification technique. Parfois appelées colonnes
calculées ou colonnes virtuelles, leurs valeurs dérivent de celles des autres
colonnes de la table. Un des articles de Markus Winand passe au crible les
différents systèmes du marché pour voir s’ils respectent ce standard.
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 !