Carnet de découvertes

Sauvegardes personnelles avec Restic

Florent Jardin — Wed, 08 Oct 2025 16:00:00 +0200

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.

Prise en main éclair

J’ai lu plusieurs articles et avis au sujet de Restic. Je l’avais vite identifié comme un outil équivalent à BorgBackup, mais je ne m’étais pas pressé de le tester. Quelle erreur ! J’ai été déconcerté par la facilité d’utilisation, par son interface en ligne de commande claire et complète, et par sa documentation de qualité.

Pour avoir régulièrement vécu des dégâts sur des clés de mauvaise qualité avec ma pratique exotique sur BorgBackup, je m’étais penché sur la possibilité de sauvegarder vers un dossier distant avec SSH. J’ai du insisté deux bonnes heures à l’époque sans parvenir à quoique ce soit avec Borg.

Avec Restic, ce n’est pas moins de 13 types différents de dépôts supportés, dont le SFTP. Il ne m’en fallait pas plus pour tourner le dos à son homologue. La mise en place d’un dépôt est simplifiée à l’extrême :

set -x RESTIC_REPOSITORY "sftp:<server>:<directory>"
restic init
restic backup ~ \
 --dry-run \
 --exclude-file ~/.config/restic/excludes.txt

Je ne suis pas en reste avec une gestion poussée des stratégies de rétention des instantanés. Pour l’exemple, je maintiens une sauvegarde par semaine, pendant trois mois.

restic forget --prune --keep-within-weekly 3m

La technique d’exploration d’un instantané est identique à Borg, avec un montage FUSE sous Linux. Une fois encore, la documentation est limpide à ce sujet.

sudo install -o $USER -g $USER -d /mnt/restic
restic mount /mnt/restic

Planification avec systemd

Je me suis prêté au même jeu qu’avec BorgBackup sur ma précédente installation Debian. En lieu et place de cron, je planifie mes sauvegardes avec un timer utilisateur pour déclencher une tâche deux fois par jour sur mes journées de travail.

# ~/.config/systemd/user/restic.timer
[Unit]
Description=Daily Restic backup
Documentation=man:restic

[Timer]
OnCalendar=Mon..Fri 09:30
OnCalendar=Mon..Fri 16:30
Persistent=true

[Install]
WantedBy=timers.target

La tâche consiste à appeler restic avec mon fichier d’exclusion, suivi d’une purge des vieux instantanés présents sur le dépôt.

# ~/.config/systemd/user/restic.service
[Unit]
Description=Restic backup

[Service]
Type=oneshot
ExecStart=restic backup %h --exclude-file $RESTIC_EXCLUDE_FILE
ExecStartPost=restic forget --prune --keep-within-weekly 3m

Pour la configuration, je déclare les variables dans un fichier d’environnement pour que restic sache identifier et déchiffrer correctement les instantanés.

# ~/.config/environment.d/restic.conf
RESTIC_REPOSITORY=sftp:<server>:<directory>
RESTIC_PASSWORD_FILE=$HOME/.config/restic/pass
RESTIC_EXCLUDE_FILE=$HOME/.config/restic/excludes.txt

Pour armer la planification, il suffit de recharger systemd.

systemctl --user daemon-reload

En exportant les bonnes variables dans votre shell, la consultation des instantanés se fait sobrement avec la commande suivante.

restic snapshots

repository 3db74709 opened (version 2, compression level auto)
ID Time Host Tags Paths Size
-----------------------------------------------------------------------------------
f7bb4fea 2025-09-16 11:50:18 florent-dalibo /home/florent 4.309 GiB
5a4dbf59 2025-09-19 09:30:01 florent-dalibo /home/florent 5.639 GiB
1012f0ab 2025-09-27 19:28:38 florent-dalibo /home/florent 5.871 GiB
629c2687 2025-10-03 09:30:00 florent-dalibo /home/florent 6.006 GiB
98b32adb 2025-10-08 10:00:08 florent-dalibo /home/florent 4.677 GiB
-----------------------------------------------------------------------------------
5 snapshots

Conclusion

Restic est un bon outil. Tellement bon, que la communauté Gnome l’utilise à présent comme backend pour l’interface Déjà Dup dans leur dernière version 49.0 sortie le mois dernier.

Pour ma part, tout se déroule bien depuis presque un mois. Il ne manque plus qu’à sécuriser le serveur distant qui fait office de dépôt avec ses propres sauvegardes ! Pour ce faire, j’envisage de mettre en place Restic sur la plupart des répertoires d’importances de mon serveur multimédia, en gardant bien en mémoire le principe 3-2-1 de la sauvegarde réussie.

Prenez soin de vos sauvegardes.

Le partitionnement par UUID v7

Florent Jardin — Tue, 17 Jun 2025 10:45:00 +0200

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.

Explorer les limites

En première lecture de la documentation, nous pouvons prendre conscience que le choix de la clé de partitionnement est crucial pour parvenir au meilleur compromis stockage/performance. Parmi les contraintes qui s’imposent à nous, l’une d’entre elles est particulièrement fondamentale :

Pour créer une contrainte d’unicité ou une clé primaire sur une table partitionnée, la clé de partitionnement ne doit pas inclure des expressions ou des appels de fonction, et les colonnes de la contrainte doivent inclure toutes les colonnes de la clé de partitionnement. Cette limitation existe parce que les index individuels créant la contrainte peuvent seulement forcer l’unicité sur leur propre partition ; de ce fait, la structure même de la partition doit garantir qu’il n’existe pas de duplicats dans les différentes partitions.

Documentation : https://www.postgresql.org/docs/current/ddl-partitioning.html

En résumé, si nous souhaitons une contrainte de clé primaire sur notre table partitionnée, il nous faut y inclure la colonne présente dans la clé de partitionnement.

Voyons par l’exemple l’application de cette règle. Un des nombreux cas concernés par cette limitation est le partitionnement par date, à des fins de purges ou d’archivage. Une contrainte de clé primaire est requise pour identifier chaque ligne et un champ timestamp est utilisé pour catégoriser les lignes selon leur date de création.

CREATE TABLE foo (
 id bigint NOT NULL,
 name varchar,
 created_at timestamp NOT NULL
) PARTITION BY RANGE (created_at);
-- CREATE TABLE

ALTER TABLE foo ADD PRIMARY KEY (id);
-- ERROR: unique constraint on partitioned table must include all
-- partitioning columns
-- DETAIL: PRIMARY KEY constraint on table "foo" lacks column "created_at"
-- which is part of the partition key.

Pour respecter l’unicité entre toutes les partitions, PostgreSQL se simplifie la tâche en renforçant la contrainte au moment de la distribution des lignes dans les partitions. Ainsi, chaque partition dispose d’un index unique pour le respect de la contrainte d’identité, sans se soucier d’un risque de collision entre deux lignes de partitions différentes.

Reprenons notre exemple pour y entrevoir les dérives qu’apporte ce choix de modélisation. Ici, nous respecterons à la lettre ce que PostgreSQL nous impose, à savoir : inclure la colonne created_at dans la contrainte de clé primaire.

ALTER TABLE foo ADD PRIMARY KEY (id, created_at);
-- ALTER TABLE

CREATE TABLE foo_p202506 PARTITION OF foo
 FOR VALUES FROM ('2025-06-01') TO ('2025-07-01');
-- CREATE TABLE

CREATE TABLE foo_default PARTITION OF foo DEFAULT;
-- CREATE TABLE

Avec ce choix, il devient possible d’insérer deux valeurs id identiques, pour peu que leurs dates de création soient différentes. L’identité n’est donc plus un simple numéro, mais un couple id, timestamp à questionner systématiquement lors d’une consultation avec la clause WHERE.

INSERT INTO foo (id, created_at)
 VALUES (1, '2025-06-04'), (1, '2024-01-01');
-- INSERT 0 2

SELECT tableoid::regclass partname, id, created_at FROM foo;
-- partname | id | created_at
-- -------------+----+---------------------
-- foo_p202506 | 1 | 2025-06-04 00:00:00
-- foo_default | 1 | 2024-01-01 00:00:00

Les choses empirent lorsqu’une relation de clé étrangère s’immisce dans le casse-tête de la modélisation. En effet, le maintien de l’identité composite d’une ligne se révèle acrobatique, lors de la rédaction des requêtes SQL d’insertion et de jointure.

CREATE TABLE bar (
 id bigint PRIMARY KEY,
 data text,
 created_at timestamp NOT NULL,
 foo_id bigint,
 foo_created_id timestamp,
 FOREIGN KEY (foo_id, foo_created_id)
 REFERENCES foo (id, created_at)
);
-- CREATE TABLE

WITH foo_insert AS (
 INSERT INTO foo (id, name, created_at)
 VALUES (2, 'foo', clock_timestamp())
 RETURNING id, created_at
) INSERT INTO bar (id, data, created_at, foo_id, foo_created_id)
 SELECT 1, 'bar', clock_timestamp(), f.id, f.created_at
 FROM foo_insert AS f;
-- INSERT 0 1

SELECT bar.id, bar.created_at, data, foo.id, foo.name
 FROM bar
 JOIN foo
 ON foo.id = bar.foo_id
 AND foo.created_at = bar.foo_created_id;
-- id | created_at | data | id | name
-- ----+----------------------------+------+----+------
-- 1 | 2025-06-16 20:12:02.101194 | bar | 2 | foo

L’exercice devient catastrophique lorsque la seconde table requiert d’être partitionnée à son tour, et où le risque de mauvaise rédaction des requêtes augmente selon le degré de connaissance du modèle par les équipes de développement. Nous retiendrons que cette pratique n’a pas cours et se conclut fréquemment par un retour arrière.

La version 7 du type UUID

La RFC 9562 voit le jour en mai 2024 et propose d’étendre le type de données UUID de trois nouvelles versions (6, 7 et 8). Un UUID (ou Universally Unique IDentifier) est une donnée encodée sur 16 octets, garantissant une unicité à travers le temps (son heure de génération) et l’espace (son serveur de génération). Les UUID sont redoutables dans un contexte de systèmes distribués où chaque participant peut créer de la donnée (une ligne) sans risque de collision avec une autre donnée.

La structure d’un UUID v7 se voit doté d’un timestamp UNIX d’une précision à la milliseconde, encodé dans les 48 premiers bits de sa valeur. Cette version est un compromis entre la randomicité et la praticité. Les bénéfices vous paraîtront limpides à l’issue de cet article.

La version 7 était unanimement attendue, car elle apporte une réponse bien plus appropriée pour l’indexation dans les bases de données, offrant à la fois une unicité et une sortabilité pour les champs. Auparavant, l’indexation sur une donnée UUID v4 était désastreuse pour le cache et la fragmentation. Avec cet accroissement monotone des UUID au fil du temps, la gestion interne d’un index B-Tree se voit naturellement facilitée avec un équilibrage moins fréquent et une prédictibilité dans ses performances.

Une publication récente annonçait des gains significatifs entre la version 4 et la version 7, sur les insertions, les consultations par index ainsi que sur l’espace occupé par les tables et les index. De quoi se réconcilier avec le type UUID !

Metric	UUIDv4	UUIDv7	Improvement
Insert Time (10M rows)	5 min 35 sec	3 min 38 sec	~35% faster
Table Size	3618 MB	3443 MB	~5% smaller
Index Size	776 MB	602 MB	~22% smaller
Point Lookup Latency	0.167 ms	0.038 ms	~4x faster
Range Scan Latency	8.284 ms	3.791 ms	~2x faster

La communauté de développement de PostgreSQL a suivi l’actualité de cette RFC, en proposant un premier patch en février 2023 alors que le brouillon de l’Internet Engineering Task Force (IETF) venait d’être publié. C’est lors du CommitFest de janvier 2025 que le sujet est clôturé avec l’ajout dans le commit 78c5e14 de deux méthodes pour la version 18, annoncée à l’automne prochain.

author Masahiko Sawada <msawada@postgresql.org>
 Wed, 11 Dec 2024 23:54:41 +0000 (15:54 -0800)
committer Masahiko Sawada <msawada@postgresql.org>
 Wed, 11 Dec 2024 23:54:41 +0000 (15:54 -0800)
Add UUID version 7 generation function.

This commit introduces the uuidv7() SQL function, which generates UUID
version 7 as specified in RFC 9652. UUIDv7 combines a Unix timestamp
in milliseconds and random bits, offering both uniqueness and
sortability.
This commit also expands the uuid_extract_timestamp() function to
support UUID version 7.

Additionally, an alias uuidv4() is added for the existing
gen_random_uuid() SQL function to maintain consistency.

Vous me voyez venir ? À l’aide de cette nouvelle RFC, il devient possible de disposer d’une colonne d’identité contenant une valeur temporelle et qui devient de facto, une candidate idéale pour la clé de partitionnement. Le tout sans surcoût pour le stockage, car chaque champ UUID consommera 16 octets, autant qu’un bigint (8 octets) et un timestamp (8 octets) réunis !

Partitionner par UUID v7

L’idée originale me vient d’un article de Daniel Vérité, lu l’été dernier, alors même que la RFC venait de sortir, mais que le patch dans PostgreSQL était bloqué par la période de gel avant la sortie de la version 17. Il était question de pouvoir implémenter ses propres méthodes en PL/pgSQL sur les versions en vigueur, sans attendre la version 18.

La création de la table foo se réalise ainsi :

CREATE TABLE foo (
 id uuid PRIMARY KEY DEFAULT uuidv7(),
 name varchar
) PARTITION BY RANGE (id);
-- CREATE TABLE

CREATE TABLE foo_p202506 PARTITION OF foo
 FOR VALUES FROM (uuidv7_boundary('2025-06-01'))
 TO (uuidv7_boundary('2025-07-01'));
-- CREATE TABLE

CREATE TABLE foo_default PARTITION OF foo DEFAULT;
-- CREATE TABLE

La méthode uuidv7_boundary est inédite et n’a pas d’équivalent dans les versions à venir de PostgreSQL, bien qu’elle mériterait amplement sa place. Sa définition est disponible sur le dépôt dverite/postgres-uuidv7-sql.

CREATE FUNCTION uuidv7_boundary(timestamptz) RETURNS uuid
AS $$
 /* uuid fields: version=0b0111, variant=0b10 */
 select encode(
 overlay('\x00000000000070008000000000000000'::bytea
 placing substring(
 int8send(
 floor(extract(epoch from $1) * 1000)::bigint) from 3)
 from 1 for 6),
 'hex')::uuid;
$$ LANGUAGE sql stable strict parallel safe;

Grâce à cette fonction, il est possible d’obtenir les bornes d’une partition en ne conservant que la donnée temporelle d’un UUID et en remplissant le reste par des zéros (et quelques bits fixes). Pour la table foo, on se retrouve dès lors avec la partition qui respecte les valeurs comprises entre juin et juillet.

 Partitioned table "public.foo"
 Column | Type | Collation | Nullable | Default
--------+-------------------+-----------+----------+----------
 id | uuid | | not null | uuidv7()
 name | character varying | | |

Partition key: RANGE (id)
Indexes:
 "foo_pkey" PRIMARY KEY, btree (id)
Partitions: foo_p202506 FOR VALUES
 FROM ('0197285b-e300-7000-8000-000000000000')
 TO ('0197c2da-ab00-7000-8000-000000000000'),
 foo_default DEFAULT

INSERT INTO foo (name) VALUES ('foo');
-- INSERT 0 1

SELECT tableoid::regclass partname, *,
 uuid_extract_timestamp(id) created_at
 FROM foo \gx
-- -[ RECORD 1 ]------------------------------------
-- partname | foo_p202506
-- id | 01977a44-364a-752a-b62e-c026ac2f930d
-- name | foo
-- created_at | 2025-06-16 21:43:00.17+02

Une pratique en bonne voie

Au cours de ma prise de parole, le temps m’avait manqué pour conclure. Les adeptes de l’extension pg_partman ne seront pas complètement réjouis d’apprendre que le support du partitionnement automatique pour une colonne de type UUID est partiellement implémenté.

La gestion de types text et uuid a été apportée en novembre 2024, permettant ce genre de magie pour provisionner un certain nombre de partitions. Les fonctions partman.uuid7_time_encoder et partman.uuid7_time_decoder sont équivalentes respectivement aux fonctions précédentes uuidv7_boundary et uuid_extract_timestamp.

CREATE TABLE foo (
 id uuid PRIMARY KEY DEFAULT uuidv7(),
 name varchar
) PARTITION BY RANGE (id);
-- CREATE TABLE

SELECT partman.create_parent(
 p_parent_table := 'public.foo',
 p_control := 'id',
 p_interval := '1 month',
 p_time_encoder := 'partman.uuid7_time_encoder',
 p_time_decoder := 'partman.uuid7_time_decoder'
);
-- create_parent
-- ---------------
-- t

Cependant, le déplacement automatique des lignes de la partition default vers une autre au cours de la maintenance par partition_data_time() provoque encore une erreur à l’heure de la rédaction de cet article. La PR 739, proposée en janvier dernier, tente de corriger en grande partie les angles morts des travaux engagés.

SELECT * FROM partman.partition_data_time(
 p_parent_table => 'public.foo'
);
-- ERROR: Cannot run on partition set without time
-- based control column or epoch flag set with
-- an id column. Found control: uuid, epoch: none
-- CONTEXT: PL/pgSQL function partman.partition_data_time()
-- line 63 at RAISE

Le mot de la fin

Les articles que j’ai énoncés précédemment me conforte dans l’idée que le type UUID dans sa version 7 est une belle opportunité pour l’adoption de PostgreSQL, notamment pour ce cas d’usage du partitionnement par date.

L’accueil que cette rapide présentation a reçu m’a fait également l’effet d’un appel d’air par l’audience, voyant dans l’UUID un moyen de pousser les limites du moteur de base de données relationnel et open-source le plus avancé au monde.

Substituer une variable dans un script SQL

Florent Jardin — Mon, 25 Nov 2024 09:00:00 +0100

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.

Substituer une variable…

Comme point de départ, penchons-nous sur la syntaxe supportée par l’outil d’Oracle avec un exemple fil rouge. Nous incarnons un utilisateur qui souhaite obtenir le résultat des ventes d’une société factice, en appliquant deux filtres basés sur un numéro produit et deux dates passées en paramètres.

-- sqlplus-report-01.sql
CONNECT user/password@database

DEF product_id = '&1'
DEF start_date = '&2'
DEF end_date = '&3'

SELECT NVL(SUM(amount), 0) AS total_amount
 FROM orders
 JOIN products USING (product_id)
 WHERE product_id = &product_id
 AND order_date BETWEEN TO_DATE('&start_date', 'YYYY-MM-DD')
 AND TO_DATE('&end_date', 'YYYY-MM-DD');

QUIT

$ sqlplus -S /nolog @sqlplus-report-01.sql 20 2024-11-01 2024-11-30
old 3: WHERE product_id = &product_id
new 3: WHERE product_id = 20
old 4: AND order_date BETWEEN TO_DATE('&start_date', 'YYYY-MM-DD')
new 4: AND order_date BETWEEN TO_DATE('2024-11-01', 'YYYY-MM-DD')
old 5: AND TO_DATE('&end_date', 'YYYY-MM-DD')
new 5: AND TO_DATE('2024-11-30', 'YYYY-MM-DD')

TOTAL_AMOUNT
------------
 1378.98

Comme nous pouvons l’observer, la substitution s’opère en SQL*Plus dès que le caractère & est rencontré, que son contenu soit ou non entouré de guillemets simples. En début de script, j’ai appliqué une stratégie simple en définissant une variable avec un nom évocateur, pour faciliter la lisibilité et la maintenance du script et ne plus s’accommoder des variables nommées selon leur position dans la liste des arguments.

Pour obtenir un résultat équivalent avec psql, nous devons effectuer une assignation de variables en dehors du script, avec l’option -v ou --set fournie par psql. Ces variables seront alors substituées dans le script à l’aide du mécanisme d’interpolation.

-- psql-report-01.sql
\pset footer off

SELECT COALESCE(SUM(amount), 0) AS total_amount
 FROM orders
 JOIN products USING (product_id)
 WHERE product_id = :product_id
 AND order_date BETWEEN :'start_date'::date
 AND :'end_date'::date;

$ psql -f psql-report-01.sql \
$ -v product_id=20 \
$ -v start_date='2024-11-01' -v end_date='2024-11-30'
 total_amount
--------------
 1378.98

La reprise du script original est tout à fait triviale, on y retrouve une syntaxe similaire avec le caractère : en lieu et place de &. Toutefois, si la variable doit être comprise entre deux guillemets simples, nous constatons que le caractère : doit être saisi à l’extérieur et non à l’intérieur.

… dans un bloc anonyme

Les choses se gâtent lorsque le script devient plus complexe, et nécessite de manipuler nos précédentes variables dans un bloc anonyme PL/SQL. Reprenons notre script pour l’enrichir d’un message personnalisé si le produit demandé n’existe pas. Une première lecture sur la table products peut, éventuellement, retourner l’exception NO_DATA_FOUND que nous souhaitons intercepter.

-- sqlplus-report-02.sql
CONNECT user/password@database

DEF product_id = '&1'
DEF start_date = '&2'
DEF end_date = '&3'

SET serveroutput ON
SET feedback OFF
SET verify OFF

DECLARE
 p_id products.product_id%TYPE;
 p_sum NUMBER;
 p_start DATE := TO_DATE('&start_date', 'YYYY-MM-DD');
 p_end DATE := TO_DATE('&end_date', 'YYYY-MM-DD');

BEGIN
 SELECT product_id INTO p_id
 FROM products
 WHERE product_id = &product_id;

 SELECT NVL(SUM(amount), 0) INTO p_sum
 FROM orders
 WHERE product_id = p_id
 AND order_date BETWEEN p_start AND p_end;

 DBMS_OUTPUT.PUT_LINE('Total amount: ' || p_sum);

EXCEPTION
 WHEN NO_DATA_FOUND THEN
 DBMS_OUTPUT.PUT_LINE('Product ' || &product_id || ' does not exist');
END;
/

QUIT

$ sqlplus -S /nolog @sqlplus-report-02.sql 120 2024-11-01 2024-11-30
Product 120 does not exist

Du côté de notre alternative PostgreSQL et son invite de commande psql, il apparaît qu’un bloc anonyme en PL/pgSQL ne permet pas de réaliser la substitution comme nous le souhaitons. Si nous tentons de réaliser un contrôle avec le renvoi d’une exception, nous obtenons une erreur de syntaxe, car la variable n’est pas substituée.

-- psql-report-02-wrong.sql
DO $$
DECLARE
 p_id products.product_id%TYPE;
 p_sum numeric;
 p_start date := :'start_date'::date;
 p_end date := :'end_date'::date;

BEGIN
 SELECT product_id INTO STRICT p_id
 FROM products
 WHERE product_id = :product_id;

 SELECT COALESCE(SUM(amount), 0) INTO p_sum
 FROM orders
 WHERE product_id = p_id
 AND order_date BETWEEN p_start AND p_end;

 RAISE NOTICE 'Total amount: %', p_sum;

EXCEPTION
 WHEN no_data_found THEN
 RAISE NOTICE 'Product % does not exist', :product_id;
END;
$$;

$ psql -f psql-report-02-wrong.sql \
$ -v product_id=120 \
$ -v start_date='2024-11-01' -v end_date='2024-11-30'
psql:psql-report-02-wrong.sql:25: ERROR: syntax error at or near ":"
LINE 5: p_start date := :'start_date'::date;
 ^

Fort heureusement, psql ne nous laisse pas sans ressource. Les méta-commandes qu’il propose peuvent nous permettre d’obtenir le même résultat, moyennant une réécriture plus profonde du script. Nous allons utiliser la méta-commande \gset pour stocker l’état du produit puis la méta-commande \if pour réaliser le contrôle.

-- psql-report-02.sql
\pset footer off

SELECT NOT EXISTS(
 SELECT product_id
 FROM products
 WHERE product_id = :product_id
) AS unknown_product \gset

\if :unknown_product
 \echo 'Product' :product_id 'does not exist'
 \quit
\endif

SELECT COALESCE(SUM(amount), 0) AS total_amount
 FROM orders
 JOIN products USING (product_id)
 WHERE product_id = :product_id
 AND order_date BETWEEN :'start_date'::date
 AND :'end_date'::date;

$ psql -f report.sql \
$ -v product_id=120 \
$ -v start_date='2024-11-01' -v end_date='2024-11-30'
Product 120 does not exist

… à tout prix

Il est probable que les méta-commandes de psql ne viennent pas à bout de toutes les ingéniosités (et aberrations) que peuvent réserver les scripts compatibles avec SQL*Plus. Progressons encore avec une évolution plus complexe de notre exemple.

Notre utilisateur souhaite à présent obtenir un score de performance pour la période de vente de son produit, en comparant avec la période précédente. Nous aurions besoin ici d’un curseur pour réutiliser plusieurs fois la même requête de calcul des ventes ainsi que d’une fonction pour calculer le score de performance en gérant correctement la division possible par zéro.

-- sqlplus-report-03.sql
CONNECT user/password@database

DEF product_id = '&1'
DEF start_date = '&2'
DEF end_date = '&3'

SET serveroutput ON
SET feedback OFF
SET verify OFF

DECLARE
 p_id products.product_id%TYPE;
 p_sum NUMBER;
 p_prev_sum NUMBER;
 p_start DATE := TO_DATE('&start_date', 'YYYY-MM-DD');
 p_end DATE := TO_DATE('&end_date', 'YYYY-MM-DD');
 p_prev_start DATE := p_start - (p_end - p_start);
 p_prev_end DATE := p_start - 1;

 CURSOR c_orders (v_start DATE, v_end DATE) IS
 SELECT SUM(amount) AS total_amount
 FROM orders
 WHERE product_id = p_id
 AND order_date BETWEEN v_start AND v_end;

 FUNCTION score(p_sum NUMBER, p_prev_sum NUMBER)
 RETURN NUMBER IS
 v_score NUMBER;
 BEGIN
 RETURN ROUND((p_sum - p_prev_sum) / p_prev_sum * 100, 2);
 EXCEPTION
 WHEN ZERO_DIVIDE THEN
 RETURN NULL;
 END;

BEGIN
 SELECT product_id INTO p_id
 FROM products
 WHERE product_id = &product_id;

 OPEN c_orders(p_start, p_end);
 FETCH c_orders INTO p_sum;
 CLOSE c_orders;

 OPEN c_orders(p_prev_start, p_prev_end);
 FETCH c_orders INTO p_prev_sum;
 CLOSE c_orders;

 DBMS_OUTPUT.PUT_LINE('Total amount: ' || p_sum);
 DBMS_OUTPUT.PUT_LINE('Performance score: ' || score(p_sum, p_prev_sum));

EXCEPTION
 WHEN NO_DATA_FOUND THEN
 DBMS_OUTPUT.PUT_LINE('Product ' || &product_id || ' does not exist');
END;
/

QUIT

$ sqlplus -S /nolog @sqlplus-report-03.sql 20 2024-11-01 2024-11-30
Total amount: 1378.98
Performance score: 162.99

Bien que l’exemple soit volontairement simpliste et qu’il puisse faire appel à une fonction de fenêtrage, nous allons jouer le jeu de la conversion du script au plus proche de sa syntaxe originale. Pour cela, identifions les faiblesses du PL/pgSQL.

Les routines éphémères ne sont pas prises en charge

Le langage PL/pgSQL n’autorise pas la déclaration de fonctions ou de procédures stockées dont la portée serait exclusive au contexte d’exécution. La seule alternative est de définir globalement la routine, afin qu’elle soit connue de l’analyseur syntaxique et exécutée correctement. Dans le cas présent, je ne souhaite pas que la fonction persiste après l’appel de mon script. Qu’à cela ne tienne, nous pouvons créer une fonction temporaire dans le schéma pg_temp !

-- temp-function.sql
DO $$
BEGIN
 CREATE FUNCTION pg_temp.score(p_sum numeric, p_prev_sum numeric)
 RETURNS numeric LANGUAGE plpgsql AS $func$
 BEGIN
 RETURN ROUND((p_sum - p_prev_sum) / p_prev_sum * 100, 2);
 EXCEPTION
 WHEN division_by_zero THEN
 RETURN NULL;
 END;
 $func$;

 RAISE NOTICE 'Score: %', pg_temp.score(100.0, 50.0);
 RAISE NOTICE 'Score: %', pg_temp.score(100.0, 0);
END;
$$;

$ psql -f temp-function.sql
psql:temp-function.sql:16: NOTICE: Score: 100.00
psql:temp-function.sql:16: NOTICE: Score: <NULL>
DO

La fonction pg_temp.score(numeric, numeric) est dès lors accessible dans le reste de notre bloc anonyme, et ce, uniquement pour la durée de la session. La gestion des exceptions est conforme au besoin, il a suffit de remplacer ZERO_DIVIDE par division_by_zero comme le stipule la documentation.

La substitution ne s’applique pas dans un bloc anonyme

Comme nous l’avons vu précédemment, la substitution n’intervient pas lorsque nous nous trouvons dans un bloc de code PL/pgSQL. Pour contourner cette limitation, nous allons devoir utiliser les variables de session personnalisées mises à disposition pour l’écosystème d’extensions avec PostgreSQL.

Ces variables peuvent être manipulées aussi bien en psql avec le mot-clé SET qu’en SQL ou en PL/pgSQL avec les fonctions current_setting et set_config. La seule contrainte consiste à leur définir un préfixe qui n’entre pas en conflit avec celui d’autres variables déjà déclarées dans notre instance.

Pour revenir à notre exercice de conversion, cela signifie que nos paramètres de script peuvent être montés en variables de session dans les toutes premières instructions. Dès que nous sommes dans un bloc anonyme, il convient alors de les rappeler dans des variables classiques comme le montre le code suivant :

SET my.product_id = :product_id;
SET my.start_date = :start_date;
SET my.end_date = :end_date;

DO $$
DECLARE
 my_id int := current_setting('my.product_id')::int;
 p_start date := current_setting('my.start_date')::date;
 p_end date := current_setting('my.end_date')::date;
BEGIN
 ...
END;
$$;

Conversion complète

Toutes ces astuces mises bout à bout permet d’obtenir une nouvelle version du script, converti de PL/SQL à PL/pgSQL :

-- psql-report-03.sql
\set QUIET on

SET my.product_id = :product_id;
SET my.start_date = :'start_date';
SET my.end_date = :'end_date';

DO $$
DECLARE
 my_id int := current_setting('my.product_id')::int;
 p_id products.product_id%TYPE;
 p_sum numeric;
 p_prev_sum numeric;
 p_start date := current_setting('my.start_date')::date;
 p_end date := current_setting('my.end_date')::date;
 p_prev_start date := p_start - interval '1 day' * (p_end - p_start);
 p_prev_end date := p_start - interval '1 day';

 c_orders CURSOR (v_start date, v_end date) IS
 SELECT COALESCE(SUM(amount), 0)
 FROM orders
 WHERE product_id = p_id
 AND order_date BETWEEN v_start AND v_end;

BEGIN
 CREATE FUNCTION pg_temp.score(p_sum numeric, p_prev_sum numeric)
 RETURNS numeric LANGUAGE plpgsql AS $func$
 BEGIN
 RETURN ROUND((p_sum - p_prev_sum) / p_prev_sum * 100, 2);
 EXCEPTION
 WHEN division_by_zero THEN
 RETURN NULL;
 END;
 $func$;

 SELECT product_id INTO STRICT p_id
 FROM products
 WHERE product_id = my_id;

 OPEN c_orders(p_start, p_end);
 FETCH c_orders INTO p_sum;
 CLOSE c_orders;

 OPEN c_orders(p_prev_start, p_prev_end);
 FETCH c_orders INTO p_prev_sum;
 CLOSE c_orders;

 RAISE NOTICE 'Total amount: %', p_sum;
 RAISE NOTICE 'Performance score: %', pg_temp.score(p_sum, p_prev_sum);

EXCEPTION
 WHEN no_data_found THEN
 RAISE NOTICE 'Product % does not exist', my_id;
END;
$$;

$ psql -f psql-report-03.sql\
$ -v product_id=20 \
$ -v start_date='2024-11-01' -v end_date='2024-11-30'
psql:psql-report-03.sql:55: NOTICE: Total amount: 1378.98
psql:psql-report-03.sql:55: NOTICE: Performance score: 162.99

Conclusion

Convertir un script SQL*Plus pour qu’il devienne compatible avec l’outil psql de PostgreSQL est un exercice surmontable, pour peu que l’on connaisse les bonnes astuces et alternatives qui répondent au besoin initial. Bien sûr, une traduction un pour un, en conservant la syntaxe et un semblant de lisibilité, pourrait s’avérer plus ardue que l’exemple que j’ai concocté.

Je reste toujours sceptique face à celles et ceux qui souhaitent conserver ce genre de pratiques de développement, que je trouve obsolètes. Migrer vers PostgreSQL n’est-il pas l’occasion de moderniser sa base de code, ou de questionner son rapport à la technologie ? Dans notre exemple, comme je l’avais mentionné, il est possible d’obtenir le même résultat en une seule requête SQL, sans avoir à recourir à un bloc anonyme PL/pgSQL.

-- psql-report-04.sql
\pset footer off

SELECT NOT EXISTS(
 SELECT product_id
 FROM products
 WHERE product_id = :product_id
) AS unknown_product \gset

\if :unknown_product
 \echo 'Product' :product_id 'does not exist'
 \quit
\endif

SELECT :'end_date'::date - :'start_date'::date AS days \gset
SELECT :'start_date'::date - :days AS prev_start \gset

WITH periods AS (
 SELECT d AS start_date, d + :days * '1 day'::interval AS end_date
 FROM generate_series(:'prev_start'::date,
 :'start_date'::date,
 :days * '1 day'::interval) AS s(d)
), amounts AS (
 SELECT start_date, COALESCE(SUM(amount), 0) AS total_amount,
 LAG(SUM(amount), 1) OVER (ORDER BY start_date) AS prev_total_amount
 FROM orders
 JOIN periods ON order_date BETWEEN start_date AND end_date
 WHERE product_id = :product_id
 GROUP BY start_date
)
SELECT total_amount,
 ROUND((total_amount - prev_total_amount) /
 prev_total_amount * 100, 2) AS performance_score
 FROM amounts
 WHERE prev_total_amount IS NOT NULL;

$ psql -f psql-report-04.sql\
$ -v product_id=20 \
$ -v start_date='2024-11-01' -v end_date='2024-11-30'
 total_amount | performance_score
--------------+-------------------
 1378.98 | 162.99

Tous les scripts de cet article, ainsi que les commandes DDL pour construire le modèle de données, sont disponibles cette adresse.

Poissons et coquillages

Florent Jardin — Mon, 14 Oct 2024 10:30:00 +0200

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 ?

Beurk, le Bash

Ne faisons pas de détour, le Bash c’est moche. Puissant, pratique, universel, mais moche.

Vous pourriez penser que c’est un avis parfaitement subjectif, et qu’il ne faut pas juger un livre à sa couverture… mais avouez-le, une partie de vous pense sensiblement la même chose que moi. Combien d’heures ai-je pu perdre durant ma courbe d’apprentissage du langage, à cause d’un grand nombre de subtilités et de pièges de syntaxes ?

Entre les assignations sans espace autour du signe =, les accolades {} pour les variables contenant un signe _, les backticks ` ` pour les commandes subshells, ou encore les doubles crochets [[ ... ]] pour les comparaisons non-POSIX, il y a de quoi s’arracher les cheveux.

Certain·e·s y verront une forme d’esthétisme ou de tradition d’une culture informatique, mais personnellement je trouve que c’est un langage qui vieillit mal, très mal. Vous ne vous offusqueriez pas non plus si je devais vous témoigner mon désamour le Perl, n’est-ce pas ?

# une comparaison de deux variables
[[ "$a" == "$b" ]]

# une addition et une affectation
z=$(( $x + $y ))

# une boucle for
for i in $(seq 1 10); do
 echo $i
done

# un switch case
case $1 in
 1) echo "un";;
 2) echo "deux";;
 *) echo "autre";;
esac

# une chaîne en minuscule
a=${a,,}

# une gestion des erreurs de commandes chaînées
some_command | another_command
if [[ ${PIPESTATUS[0]} -ne 0 || ${PIPESTATUS[1]} -ne 0 ]]; then
 echo "Une des commandes a échoué"
fi

Le Bash est apparu l’année de ma naissance, en 1989. Il a été conçu en opposition au Bourne Shell (sh) pour apporter des fonctionnalités de programmation plus avancées. Il est devenu le shell par défaut de la plupart des distributions Linux, et est devenu un standard pour tous les scripts à travers le monde entier.

Fort de ses années de succès, et de son emprise sur le monde Unix, le Bash s’impose parfois comme la première porte vers la programmation pour des administrateurices système ou les étudiant·e·s en informatique. Et il faut accepter que la qualité de ses premiers scripts n’est pas toujours au rendez-vous. Souvenez-vous des longues heures passées sur StackOverflow à trouver la syntaxe la plus lisible ou la plus efficace, car les réponses se révélaient aussi variées que touffues !

Et c’est l’un des plus gros problèmes que je trouve au Bash : ce langage de programmation est exigeant, excentrique, voire idiosyncratique, et qui ne pardonne pas les erreurs. Un des paradoxes que j’associe au Bash est qu’il peut ne pas être considéré comme un véritable langage de programmation, réduisant ainsi la volonté et l’effort de l’apprendre en profondeur par une large communauté de professionnel·le·s.

Et si vos scripts Bash sont nuls, utilisez un autre langage.

L’ami Fish, Friendly Interactive Shell

Je suis tombé sur Fish par hasard, alors que je questionnais mon usage quotidien sur ZSH. Sur mon poste personnel, j’ai étendu mon expérience passée sur le Bash avec une configuration ZSH enrichie de Oh My Zsh. C’était un peu le jour et la nuit dans l’interaction avec mes terminaux : la navigation, les suggestions, les thèmes, les plugins, tout est plus fluide et plus agréable. Sa compatibilité avec Bash m’avait alors évité de tout réapprendre.

Fish répond au besoin de modernité et de simplicité que je cherche sans vraiment le savoir. Contrairement à ZSH, un grand nombre de fonctionnalités sont disponibles sans aucune configuration préalable ou plugin à activer.

Assistance à la commande

Recopie la commande incomplète et en erreur sans besoin de naviguer dans l’historique
Accès à l’historique partiel avec les touches directionnelles dès la première frappe au clavier
Proposition de chemins avec la complétion de la touche Tab, suivie des touches directionnelles

Auto-suggestions des chemins et des options d’une grande majorité des outils

Mémoire des précédents répertoires parcourus
Support très complet des commandes Git, notamment le git rebase -i ❤️

Coloration plus poussée des commandes

une couleur différente par mot selon la syntaxe employée (variables, chemin, options)
un rouge prononcé pour les commandes inconnues

Un langage qui vous veut du bien

Pour revenir au sujet principal de cet article, Fish révolutionne notre rapport avec la rédaction de scripts. Fini les pièges et la syntaxe qui nous ont tenu en otage durant des années. Les choses deviennent bien plus simples et lisibles.

# une comparaison de deux variables
test "$a" = "$b"

# une addition et une affectation
set z (math $x + $y)

# une boucle for
for i in (seq 1 10)
 echo $i
end

# un switch case
case $argv[1]
 1; echo "un"
 2; echo "deux"
 *; echo "autre"
end

# une chaîne en minuscule
set a (string lower $a)

# une gestion des erreurs de commandes chaînées
some_command | another_command
if contains 1 $pipestatus
 echo "Une des commandes a échoué"
end

L’investissement initial pour perdre ses habitudes acquises avec Bash est modéré, notamment le remplacement de export ou de l’assignation = par la méthode set -x ou set -u respectivement. Mais l’enrichissement du langage par quelques nouveaux mots-clés permet d’alléger le script avec des syntaxes claires et lisibles (contains, math ou string présents dans l’exemple ci-dessus).

L’ajout de plugins communautaire n’est pas en reste, si comme moi, vous en consommiez avec Oh-My-ZSH. L’outil Fisher s’installe dans votre ~/.config/fish et donne accès à un gestionnaire complet et sobre. Pour ma part, j’ai pu rapidement combler mon besoin de charger les variables d’environnement fournies par l’agent SSH (ssh-agent) lors du démarrage de ma session.

$ fisher install danhper/fish-ssh-agent
fisher install version 4.4.5
Fetching https://api.github.com/repos/danhper/fish-ssh-agent/tarball/HEAD
Installing danhper/fish-ssh-agent
 /home/florent/.config/fish/functions/__ssh_agent_is_started.fish
 /home/florent/.config/fish/functions/__ssh_agent_start.fish
 /home/florent/.config/fish/conf.d/fish-ssh-agent.fish
Updated 1 plugin/s

Pas de mystère, ni d’arcanes magiques, votre environnement est enrichi de nouvelles fonctions et de scripts de démarrage, développés en Fish.

Osons la modernité

La documentation du projet est très bien fournie. En plus de la page Tutorial, vous trouverez une page dédiée aux utilisateurs de Bash pour vous aider à réussir votre transition. Pour ma part, j’y retrouve des syntaxes bien plus proches du Python, et c’est un vrai plaisir.

Le projet est vivant, avec un rythme de versions régulier. Je me suis surpris moi-même à ne pas en avoir entendu parler par d’autres collègues ou auprès des auteurices de blogs que je suis. Au cours des dernières années, la communauté francophone a essaimé quelques bons articles qui complètent le mien.

Changer de shell, de Bash à Fish (2016)
Fish, une ligne de commande intelligente et simple d’utilisation (2017)
Comment passer de Bash à Fish Shell sous Linux (2021)
Migration de shell de zsh à fish (2024)

Ces temps-ci, je fais évoluer mon expérience d’utilisateur de Linux avec une transition vers Wayland et SwayWM (j’y reviendrais dans un autre article). Je ne le cache pas, la tentation de remplacer mes scripts Bash qui gèrent mes thèmes ou les composants swaybar, est forte, très forte.

De quoi occuper mes prochaines longues soirées d’hiver.

Les types hiérarchiques

Florent Jardin — Thu, 19 Sep 2024 13:20:00 +0200

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.

À la recherche de ses descendants

Conçu pour représenter une relation hiérarchique sous la forme d’un arbre binaire, le type hierarchyid a la particularité de stocker la liste des nœuds successifs jusqu’à la racine dans une seule colonne. Ainsi, le nœud /1/1/2/ représente un nœud de niveau 3, enfant du nœud /1/1/, lui-même enfant du nœud /1/, lui-même enfant de la racine /.

Plusieurs méthodes sont fournies avec le langage Transact-SQL pour manipuler les données et toutes parcourent l’arbre binaire pour en extraire rapidement l’information souhaitée sans avoir à joindre les nœuds de la table entre eux.

ToString() : retourne la représentation textuelle du nœud courant.
GetLevel() : retourne le niveau de profondeur du nœud courant.
GetAncestor(n) : retourne le nœud de niveau n dans l’arbre.
GetDescendant(c1, c2) : retourne un nouveau nœud enfant entre deux nœuds.

L’extension ltree, disponible depuis le paquet contrib de PostgreSQL, est aussi complète, voire plus, que le type hierarchyid. Elle fournit un type de données complexe, nommé ltree, et permet de stocker des labels de 1 000 caractères alphanumériques séparés par des points. Le chemin (path) ainsi constitué, peut lui-même contenir jusqu’à 65 635 labels.

CREATE EXTENSION ltree;

CREATE TABLE locations (
 id ltree PRIMARY KEY,
 location text NOT NULL,
 locationtype text NOT NULL
);

INSERT INTO locations VALUES
 ('1', 'Earth', 'Planet'),
 ('1.1', 'Europe', 'Continent'),
 ('1.1.1', 'France', 'Country'),
 ('1.1.1.1', 'Paris', 'City'),
 ('1.1.2', 'Spain', 'Country'),
 ('1.1.2.1', 'Madrid', 'City'),
 ('1.2', 'South-America', 'Continent'),
 ('1.2.1', 'Brazil', 'Country'),
 ('1.2.1.1', 'Brasilia', 'City'),
 ('1.2.2', 'Bahia', 'State'),
 ('1.2.2.1', 'Salvador', 'City'),
 ('1.3', 'Antarctica', 'Continent'),
 ('1.3.1', 'McMurdo Station', 'City');

Obtenir le niveau de profondeur d’un nœud devient trivial avec la fonction nlevel() fournie par l’extension ltree.

SELECT id, location, locationtype, nlevel(id) AS level
 FROM locations ORDER BY id;

 id | location | locationtype | level
---------+-----------------+--------------+-------
 1 | Earth | Planet | 1
 1.1 | Europe | Continent | 2
 1.1.1 | France | Country | 3
 1.1.1.1 | Paris | City | 4
 1.1.2 | Spain | Country | 3
 1.1.2.1 | Madrid | City | 4
 1.2 | South-America | Continent | 2
 1.2.1 | Brazil | Country | 3
 1.2.1.1 | Brasilia | City | 4
 1.2.2 | Bahia | State | 3
 1.2.2.1 | Salvador | City | 4
 1.3 | Antarctica | Continent | 2
 1.3.1 | McMurdo Station | City | 3
 2.1.1 | unknown | State | 3
(14 rows)

Une autre méthode nommée subpath() permet de récupérer une partie du chemin d’un nœud. Voyons comment obtenir le nœud parent de chaque nœud de la table.

SELECT id, location, locationtype, subpath(id, 0, nlevel(id) - 1) AS parentid
 FROM locations ORDER BY id;

 id | location | locationtype | parent
---------+-----------------+--------------+--------
 1 | Earth | Planet |
 1.1 | Europe | Continent | 1
 1.1.1 | France | Country | 1.1
 1.1.1.1 | Paris | City | 1.1.1
 1.1.2 | Spain | Country | 1.1
 1.1.2.1 | Madrid | City | 1.1.2
 1.2 | South-America | Continent | 1
 1.2.1 | Brazil | Country | 1.2
 1.2.1.1 | Brasilia | City | 1.2.1
 1.2.2 | Bahia | State | 1.2
 1.2.2.1 | Salvador | City | 1.2.2
 1.3 | Antarctica | Continent | 1
 1.3.1 | McMurdo Station | City | 1.3
 2.1.1 | unknown | State | 2.1
(14 rows)

Enfin, la recherche des nœuds enfants depuis un nœud donné est possible grâce aux opérateurs de comparaison spécialisés. Pour favoriser les performances, il est recommandé de créer un index GIST sur la colonne de clé primaire id.

CREATE INDEX ON locations USING GIST (id);

La requête suivante liste toutes les villes d’Europe.

SELECT l1.*
 FROM locations l1
 JOIN locations l2 ON l1.id <@ l2.id
 WHERE l1.locationtype = 'City' AND l2.location = 'Europe';

 id | location | locationtype
---------+----------+--------------
 1.1.1.1 | Paris | City
 1.1.2.1 | Madrid | City
(2 rows)

Travailler sous contraintes

La contrainte de clé primaire m’empêche actuellement d’insérer un chemin déjà existant. Par contre, il est bien possible d’ajouter une nouvelle ligne dont le chemin ne présente pas d’ancêtre dans la table.

INSERT INTO locations VALUES ('2.1.1', 'Unknown', 'Continent');

INSERT 0 1

À ce jeu, SQL Server et PostgreSQL n’ont plus trop de différences, il devient nécessaire d’ajouter une colonne supplémentaire, nommée parentid par exemple, pour ajouter la contrainte de clé étrangère. La requête suivante réutilise la fonction subpath() en s’assurant qu’une valeur nulle soit insérée s’il s’agit d’un nœud racine.

DELETE FROM locations WHERE id <@ '2';

ALTER TABLE locations ADD COLUMN parentid ltree
 REFERENCES locations (id)
 GENERATED ALWAYS AS (
 CASE subpath(id, 0, nlevel(id) - 1)
 WHEN '' THEN null
 ELSE subpath(id, 0, nlevel(id) - 1)
 END
 ) STORED;

À présent, dès qu’une nouvelle ligne est insérée, la contrainte de clé étrangère est automatiquement vérifiée.

INSERT INTO locations VALUES ('2.1.1', 'Unknown', 'Continent');

ERROR: insert or update on table "locations" violates
 foreign key constraint "locations_parentid_fkey"
DETAIL: Key (parentid)=(2.1) is not present in table "locations".

Une solution parmi d’autres

La méthode de stockage des données hiérarchiques sous forme de chemin est une solution ingénieuse et disponible facilement avec PostgreSQL. Cependant, il s’agit d’une extension du langage SQL et chaque moteur peut proposer une implémentation qui peut radicalement changer d’un système à l’autre.

Comme je l’indiquais en introduction, la réponse universelle reste la reconstruction d’une relation hiériarchique à l’aide d’une requête récursive et la syntaxe WITH RECURSIVE. Pour reprendre l’exemple de la table locations, la liste des villes présentes en Europe pourrait être obtenue de la manière suivante.

WITH RECURSIVE loc AS (
 SELECT id, parentid, location, locationtype
 FROM locations
 WHERE location = 'Europe'
 UNION ALL
 SELECT l.id, l.parentid, l.location, l.locationtype
 FROM locations l
 JOIN loc r ON l.parentid = r.id
)
SELECT * FROM loc
 WHERE locationtype = 'City';

 id | parentid | location | locationtype
----+----------+----------+--------------
 4 | 3 | Paris | City
 6 | 5 | Madrid | City
(2 rows)