Postgresql on Carnet de découvertes

Inspecter un catalogue avec pg_migrate

Florent Jardin — Tue, 15 Sep 2026 16:00:00 +0200

Au cours des dernières années, je me suis engagé à identifier les atouts et faiblesses des outils dédiés à la migration vers PostgreSQL. Plusieurs articles publiés par mes soins ont pavé le chemin vers une direction ambitieuse que j’entreprends depuis 2024 avec mes collègues Étienne Bersac et Pierre-Louis Gonon.

… Et la première version stable de PostgreSQL Migrator est sortie le 4 septembre dernier. L’occasion de présenter des fonctionnalités que j’utilise au quotidien et ce qu’elles apportent par rapport aux autres outils. Dans cet article, je souhaite m’attarder sur l’une d’entre elles, particulièrement précieuse pour préparer une migration : le catalogue hors-ligne.

Consulter le catalogue Oracle

Le catalogue d’une base de données relationnelle renferme la structure du modèle, les noms et le typage des colonnes d’une table, les options de contraintes, la définition d’une vue ou d’une fonction, etc. Tout ce qui est déclaré par l’utilisateur avec du DDL (Data Definition Language) est maintenu dans un catalogue comme unique source de vérité.

Sur les systèmes comme PostgreSQL, MySQL ou MSSQL Server, la norme encourage l’utilisation d’un catalogue universel, l’espace information_schema. Par exemple, on peut y questionner les noms des tables avec la même requête :

SELECT table_name FROM information_schema.tables
 WHERE table_schema = 'scott'
 ORDER BY table_name;

Cependant, ce n’est pas la solution idéale pour reconstruire un modèle de données. Chacun des systèmes se conforment au mieux à la norme SQL mais très fréquemment, ils l’enrichissent avec des extensions du langage ou prennent des libertés sur l’implémentation d’une fonctionnalité. Il en résulte que le catalogue information_schema n’est pas la source universelle, à peine une collection d’alias dans un catalogue système propre à chacun.

À présent, parlons d’Oracle et d’Ora2Pg. Si nous souhaitons recréer la structure d’une table depuis l’écosystème Oracle, plusieurs méthodes existent et toutes s’appuient sur les vues du catalogue que je présente en dernier.

La commande DESCRIBE

Certainement la moins riche des solutions mais la plus rapide pour une première inspection. Il s’agit d’un équivalent de la méta-commande \d dans psql ou du pragma table_info pour SQLite.

DESCRIBE SCOTT.EMP;

-- Name Null? Type
-- -------- -------- ------------
-- EMPNO NOT NULL NUMBER(4)
-- ENAME VARCHAR2(10)
-- JOB VARCHAR2(9)
-- MGR NUMBER(4)
-- HIREDATE DATE
-- SAL NUMBER(7,2)
-- COMM NUMBER(7,2)
-- DEPTNO NUMBER(2)

Le package DBMS_METADATA

Il est possible d’employer un package Oracle très utile pour générer la structure d’une table au format texte SQL. Les équivalents des autres systèmes seraient l’instruction SHOW CREATE TABLE de MySQL ou encore .schema de SQLite.

SET pagesize 0
SET long 20000
SELECT dbms_metadata.get_ddl(
 object_type => 'TABLE',
 schema => 'SCOTT',
 name => 'EMP');

-- CREATE TABLE "SCOTT"."EMP"
-- ( "EMPNO" NUMBER(4,0),
-- "ENAME" VARCHAR2(10),
-- "JOB" VARCHAR2(9),
-- "MGR" NUMBER(4,0),
-- "HIREDATE" DATE,
-- "SAL" NUMBER(7,2),
-- "COMM" NUMBER(7,2),
-- "DEPTNO" NUMBER(2,0),
-- CONSTRAINT "PK_EMP" PRIMARY KEY ("EMPNO")
-- USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255
-- STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
-- PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
-- TABLESPACE "SYSTEM" ENABLE,
-- CONSTRAINT "FK_DEPTNO" FOREIGN KEY ("DEPTNO")
-- REFERENCES "SCOTT"."DEPT" ("DEPTNO") ENABLE
-- ) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
-- STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
-- PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
-- TABLESPACE "SYSTEM"

Les vues du catalogue

Les résultats précédents sont compilés depuis plusieurs vues systèmes. Sans surprise, les explorateurs classiques comme SQL Developer ou DBeaver, ainsi qu’Ora2Pg et PostgreSQL Migrator, consultent directement les données des différentes vues pour obtenir le DDL complet.

Ora2Pg obtient la liste des tables depuis la vue ALL_OBJECTS et le stocke en mémoire dans un tableau associatif $self->{tables}. Puis, il itère sur ALL_TAB_COLUMNS pour collecter le détail de chaque table et les rattacher avec une nouvelle profondeur de ce même tableau global $self->{tables}{$table}{column_info}{$column}.

SELECT A.OWNER,A.OBJECT_NAME,A.OBJECT_TYPE FROM ALL_OBJECTS A
 WHERE A.OBJECT_TYPE IN ('TABLE','VIEW') AND A.OWNER='SCOTT';

SELECT A.COLUMN_NAME, A.DATA_TYPE, A.DATA_LENGTH, A.NULLABLE, A.DATA_DEFAULT,
 A.DATA_PRECISION, A.DATA_SCALE, A.CHAR_LENGTH, A.TABLE_NAME, A.OWNER
 FROM ALL_TAB_COLUMNS A
 WHERE A.TABLE_NAME NOT LIKE 'BIN$%' AND A.TABLE_NAME='EMP'
 ORDER BY A.COLUMN_ID

La structure en mémoire $self que maintient Ora2Pg ne persiste pas entre deux exécutions. La lecture du catalogue source est nécessaire à chaque fois. En opposition, j’ai eu l’occasion de découvrir une alternative nommée db_migrator, basée sur les Foreign Data Wrapper. Avec cette solution, le catalogue est stockée dans une base de données PostgreSQL.

Il était alors simple de lancer une inspection avec la fonction db_migrate_refresh() pour créer un instantané du catalogue distant et de pouvoir le questionner hors-ligne, sans se reconnecter à l’instance Oracle. De cette découverte émergera les premiers tâtonnements du catalogue au format JSON de PostgreSQL Migrator.

Questionner du JSON

Le stockage du catalogue requiert un format structuré, stable et non contraignant. De facto, le choix de conserver les données dans des tables PostgreSQL nous est apparu inadapté, bien qu’élégant pour des yeux de DBA. L’outil PostgreSQL Migrator se vante d’être portable et nous ne souhaitions pas encombrer l’instance PostgreSQL finale d’un schéma transitoire.

Comme Ora2Pg, une structure mémoire Catalog (internal/catalog/catalog.go) est initialisée au début de l’inspection. Ce catalogue peut être étendu en fonction que la source soit une base Oracle ou MySQL/MariaDB, pour collecter les objets spécifiques du moteur, comme les packages ou les synonymes. Dès lors que la lecture du catalogue distant est réalisée, il suffit de sérialiser la structure dans un fichier JSON. Actuellement, la version 1.0 s’appuit sur la bibliothèque sonic.

L’inspection est la première étape pour démarrer un projet avec pg_migrate, le petit nom de l’interface en ligne de commande (CLI) de PostgreSQL Migrator. Après avoir initialisé un dossier vide et valider l’accès à la base distante Oracle, les traces nous invitent à exécuter la commande pg_migrate inspect.

$ ora-scott && cd ora-scott
$ pg_migrate init --source "oracle://system:manager@localhost:1521/freepdb1"
14:55:28 INFO Databases connections closed. source=1 target=0
14:55:28 INFO Initialized migration project. source="Oracle Database 23ai Free"
14:55:28 INFO Inspect source catalog using pg_migrate inspect.
$ pg_migrate --verbose inspect
14:56:03 DEBUG Cache miss. name=Source
14:56:03 INFO Inspecting source database. driver=oracle
14:56:03 INFO This may take some time.
14:56:04 DEBUG Inspected schemas. count=1 duration=84.735201ms
14:56:05 DEBUG Inspected roles. count=6 duration=465.814794ms
14:56:06 DEBUG Inspected sequences. count=0 duration=1.050025889s
14:56:07 DEBUG Inspected routines. count=0 duration=2.794483231s
14:56:07 DEBUG Inspected views. count=0 duration=2.63147026s
14:56:21 DEBUG Inspected tables. count=4 duration=15.720365706s
14:56:31 DEBUG Inspected columns. count=18 duration=10.735219841s
14:56:41 DEBUG Inspected keys. count=2 duration=19.945416304s
14:56:44 DEBUG Inspected tables-indexes. count=0 duration=23.287211484s
14:56:48 DEBUG Inspected foreign-keys. count=1 duration=6.525976802s
14:56:58 DEBUG Inspected checks. count=0 duration=10.622190194s
14:56:58 INFO Inspected schema. name=SCOTT
14:56:58 DEBUG Inspection completed. duration=54.968668546s
...
14:57:12 INFO Inspection terminated. errs=0 online=true
14:57:12 INFO Execute pg_migrate ui to browse project.
14:57:12 INFO Execute pg_migrate dump to migrate for PostgreSQL.

Lors d’une première exécution, le catalogue local est inexistant (Cache miss. name=Source), ce qui provoque une connexion à la base distante pour le créer de toute pièce. Les fichiers de cache sont écrits dans le dossier caché .pg_migrate. Le catalogue de la source se nomme sobrement Source.json.

$ tree .pg_migrate/
.pg_migrate
├── Info.json
├── Map.json
├── Source.json
├── Stats.json
└── Target.json

Il a alors fallu me faire violence pour mettre de côté mes précieuses connaissances en SQL pour apprendre le langage jq afin de questionner les fichiers JSON d’un projet pg_migrate. Par exemple, le filtre suivant liste toutes les colonnes et leurs types de la table SCOTT.EMP :

$ set filter '.Tables[] | select (.Name == "EMP") | .Columns[] | .objectDefinition'
$ jq -r $filter < .pg_migrate/Source.json
EMPNO NUMBER(4, 0) NOT NULL
ENAME VARCHAR2(10)
JOB VARCHAR2(9)
MGR NUMBER(4, 0)
HIREDATE DATE
SAL NUMBER(7, 2)
COMM NUMBER(7, 2)
DEPTNO NUMBER(2, 0)

Bien évidemment, l’outil a fait un très long chemin depuis 2024 et cette architecture de catalogue hors-ligne est devenue la colonne vertébrale du produit. Ces fichiers ont permis d’explorer des possibilités jusqu’ici inatteignables avec Ora2Pg, en plus du mode hors-ligne.

La conversion passe d’un fichier Source.json à un fichier Target.json en lui appliquant des règles de conversion génériques et spécifiques ;
Une phase d’audit parcourt tous les nœuds pour appliquer un score, voire des annotations sur les difficultés de conversion ;
Une interface Web de type SPA (single page app) permet d’explorer les deux modèles (source et cible) pour se passer des filtres jq.

L’outil vient avec une commande dump, que l’on peut détourner pour récupérer la forme DDL d’un objet stocké dans le Target.json. Pour le moment, la commande complète est la suivante :

$ pg_migrate dump --force --section=pre-data Tables/scott.emp 2>/dev/null | cat
--
-- Name: emp; Type: TABLE; Schema: scott; Owner: scott
--

CREATE TABLE "scott"."emp" (
 "empno" smallint NOT NULL,
 "ename" varchar(10),
 "job" varchar(9),
 "mgr" smallint,
 "hiredate" timestamp,
 "sal" numeric(7, 2),
 "comm" numeric(7, 2),
 "deptno" smallint
);

ALTER TABLE "scott"."emp" OWNER TO "scott";

Conclusion

Je suis profondément fier du travail accompli avec cette première version stable. Nous concluons une aventure palpitante avec mes collègues chez Dalibo, celle de plus de deux ans de développement d’un outil libre et gratuit et qui a vocation à dépasser son illustre prédécesseur Ora2Pg. La feuille de route est claire et nous attaquons dès cette rentrée le chapitre sur la conversion de code procédural. Les fondations sont solides, le langage Go permet de répondre à de véritables besoins de simplification et de modernité.

À l’heure où les empires du numérique se gavent de nos données métiers, qu’ils siphonnent la valeur travail de nos entreprises, il est urgent de réagir et de croire qu’un autre numérique est possible. Les projets de migration deviennent complexes, exigeants, avec des profils très variés, nous tentons d’apporter une réponse qui ne repose pas exclusivement sur des agents LLM ou des services américains.

La voie du logiciel libre est devant nous depuis des décennies, il ne manque que les passerelles qui permettent de tourner le dos à ces technologies privatives de liberté, d’innovation et de moyens. À mon échelle de DBA et de Product Owner, engagé dans la coopérative Dalibo, j’œuvre pour cette urgence collective.

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.

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)

Faire vivre une communauté

Florent Jardin — Tue, 30 Jul 2024 09:30:00 +0000

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.

Le support de ma présentation est disponible à cette adresse.

Qu’est-ce qu’un PUG ?

Un « PUG » est un groupe d’utilisateur·rices de PostgreSQL, ou « PostgreSQL User Group » en anglais. Réunis régulièrement pour échanger autour de PostgreSQL, les PUGs sont des lieux de rencontres et d’apprentissage pour les personnes intéressées par ce système de gestion de base de données. Ces communautés locales sont fréquentes, particulièrement pour les logiciels libres, et permettent de fédérer les utilisateurs et utilisatrices autour d’un même outil.

À Lille, nous avons la chance d’avoir un tissu économique très dynamique, avec de nombreuses communautés, telles que le Ch’ti JUG (Java User Group), le GDG Lille (Google Developer Group), Nord Agile ou encore Software Craft Lille. Quoi de plus naturel que de vouloir proposer à une poignée de ce public des rencontres autour de PostgreSQL ?

Une page du projet PostgreSQL recense les différents PUGs à travers le monde, et il est possible d’y trouver des groupes dans de nombreux pays, dont la France. À l’heure de la rédaction de ma conférence, je dénombrais 62 groupes mondiaux, dont 5 en France : Paris, Lyon, Nantes (non référencée), Toulouse et Lille.

La plateforme Meetup est souvent utilisée pour organiser les rencontres, et pour preuve, 46 PUGs y sont affiliés. Il s’agit d’une commodité depuis plus de 10 ans, et la plupart des groupes français y sont inscrits.

La création d’un PUG reconnu par la communauté internationale est un processus simple, qui nécessite de constituer un groupe d’organisation et de postuler à l’adresse e-mail usergroups@postgresql.org. Le groupe doit respecter un certain nombre de règles, prévues par la charte des PUGs, et doit s’engager à respecter les valeurs de la communauté PostgreSQL. En substance, voici les points qu’il faut retenir :

Le groupe doit être ouvert à tous et toutes, sans discrimination.
Les rencontres doivent être proposées a minima une fois tous les deux ans.
Les rencontres ne doivent pas faire l’objet d’un accord de confidentialité (NDA).
Les rencontres sont rattachées à la zone géographique du groupe.
Une entreprise ne peut pas être représentée à 50% ou plus dans le comité d’organisation.
La sélection des conférences est à la discrétion du comité d’organisation.
Les entreprises peuvent promouvoir leurs produits et leurs services, si leurs activités facilitent l’adoption de PostgreSQL et si les contenus présentés sont de nature technique.
Le groupe doit divulguer le nom des sponsors, et peut les mentionner en introduction des rencontres.
Le PUG doit adopter un code de conduite et peut utiliser celui de la communauté PostgreSQL.

Genèse du groupe

Le groupe Meetup PostgreSQL Lille a été fondé le 25 février 2016 sur la plateforme éponyme. À l’époque, l’idée de reproduire le format des Meetup à Paris était partagée entre Guillaume Lelarge et Pierre Hilbert, deux lillois qui se croisaient régulièrement aux événements. L’une des principales motivations était de participer à la promotion du logiciel libre avec un partage de retours d’expérience pour inspirer les autres acteurs locaux.

À cette période, je fréquentais moi-même les événements organisés par le groupe Meetup Oracle Paris et Province, et je suivais avec attention les conférences autour de PostgreSQL dans ma région. La première rencontre du groupe PG Lille a eu lieu le 24 juin 2016, dans les locaux de Decathlon Campus (Villeneuve D’Ascq, 59). J’ai été séduit par le format et l’ambiance décontractée, et j’en ai gardé un excellent souvenir.

Cependant, la régularité des rencontres n’a pas été au rendez-vous du projet. L’événement suivant fut planifié plus d’une année plus tard, le 17 octobre 2017 et ce fut le seul auquel je n’ai pas pu participer. Les impératifs professionnels de Guillaume et de Pierre ne leur ont pas permis de maintenir le rythme, et le groupe a été laissé en sommeil pendant plus de trois années.

C’est en 2019 que j’ai pris la décision de reprendre le flambeau, en proposant à Pierre de me transmettre les droits d’administration du groupe. Mon arrivée chez Dalibo en tant que consultant PostgreSQL m’a donné l’opportunité de faire la rencontre d’experts passionnés, notamment Guillaume Lelarge et Stefan Fercot, qui m’ont encouragé à reprendre le projet.

Fort d’un réseau professionnel de qualité sur Twitter à l’époque, j’ai pu rapidement mobiliser une équipe de bénévoles pour organiser le Meetup du 28 janvier 2020. J’ai pu compter sur le soutien de Stefan Fercot (Dalibo), de Stéphane Definin (Think) et de Sébastien Freiss (SFEIR) pour faire de cette reprise un petit succès.

… Malheureusement, en mars de cette même année, la pandémie de COVID-19 a contraint le groupe à suspendre ses projets et je n’ai pas eu le courage de proposer des contenus en ligne, au grand dam des membres du groupe. Pour l’anecdote, aucun autre groupe Meetup de France n’a été épargné par la crise sanitaire et les restrictions en vigueur.

Une pause de deux années supplémentaires s’est imposée au groupe, avant que ne se stabilise la situation sanitaire. En 2022, j’ai ainsi contacté Lætitia Avrot, une membre très active de la communauté française, pour relancer les activités et retrouver une dynamique et un rythme pour ses membres. L’événement du 14 avril 2022 fut un soulagement pour moi, voyant que je pouvais toujours compter sur la participation de la communauté.

À partir de cet instant, aucune nouvelle ombre n’est venue assombrir le tableau, et le groupe a pu reprendre l’organisation régulière de rencontres, de deux à trois par ans. La communauté s’est élargie, et le comité d’organisation s’est renforcé avec l’arrivée de Yoann La Cancellera en 2023, qui a permis notamment de déposer une demande de reconnaissance au sein de la communauté internationale, le 24 février 2023.

How-to Meetup

En guise de conclusion à ce retour d’expérience, j’ai voulu partager toutes les étapes nécessaires pour organiser un Meetup, en appuyant sur les points cruciaux de réussites et les pièges à éviter.

Accueil : trouver le lieu d’accueil de pour l’événement

À l’image du PG Day France qui change de lieu chaque année, le groupe Meetup PG Lille a fait le choix de varier les lieux d’accueil à chaque rencontre. Cela permet de découvrir de nouveaux espaces et de stimuler la curiosité inter-communauté. Les entreprises locales sont souvent ravies de pouvoir accueillir des événements techniques, et cela permet de renforcer les liens entre les acteurs locaux.

La recherche d’un lieu est souvent la première étape de l’organisation d’un Meetup. Il est important de trouver un espace qui puisse accueillir entre dix et quarante personnes, avec un accès en transports en commun ou un parking à proximité. Pour cela, j’ai eu l’occasion d’user de plusieurs stratégies :

Le bouche-à-oreille : demander à ses contacts professionnels s’ils connaissent des lieux d’accueil potentiels
Les réseaux sociaux : publier une annonce sur Twitter ou LinkedIn pour solliciter des propositions spontanées ou des pistes à étudier
La privatisation d’un espace : contacter les espaces de coworking ou les salles de réunion pour obtenir un devis de location
S’allier avec d’autres groupes : proposer un partenariat avec un autre groupe Meetup pour partager les frais de location ou pour bénéficier d’un lieu d’accueil déjà identifié

Intervenant·es : trouver deux présentations variées

Dès le premier Meetup, Pierre et Guillaume ont fait le choix de proposer deux présentations techniques pour varier les sujets et les formats. Cela permet de toucher un public plus large et de satisfaire les attentes des membres du groupe. Cette formule a été reprise pour les rencontres suivantes, et a été un succès à chaque fois.

La recherche d’intervenant·es est un travail qui demande du temps et de la patience. Souvent, une rencontre opportune ou une discussion informelle peut déboucher sur une proposition de présentation. Le mieux est de se constituer un vivier de personnes ressources, qui pourront être sollicitées en cas de besoin. Ce n’est pas toujours facile, c’est un travail de longue haleine, mais cela en vaut la peine.

Discutez autours de vous, demandez à vos collègues, à vos amis, à vos contacts professionnels s’ils ne sont pas intéressés pour partager leur expérience ou leur expertise, ou s’ils ne connaissent pas quelqu’un qui pourrait être intéressé.

Apéro : prolonger la soirée avec un temps fort communautaire (networking)

Selon moi, c’est l’étape la plus importante de l’organisation d’un Meetup. (rires !)

C’est le moment où les membres du groupe peuvent échanger, discuter, partager, et se rencontrer. C’est un temps fort de la soirée qui me tient particulièrement à cœur, et qui est intimement lié à la réussite de l’événement. Le networking est ce qui favorise le mieux la sérendipité, la rencontre fortuite, le partage d’expérience, et la création de liens durables. Je discute des prochains projets du groupe avec les membres et le comité d’organisation, et je prends des notes sur les attentes de chacun·es et j’écoute leurs suggestions.

Bien entendu, il est important de prévoir des boissons et des encas pour prolonger la soirée. Il faut prévoir un espace pour faciliter la circulation et la création naturelle de petits groupes de discussion. Le choix d’un sponsor est principalement motivé par la prise en charge de ces frais, avec une facture ou une note de frais à l’appui.

Jusqu’à présent, aucun incident n’est à déplorer, les participants et participantes respectent les quelques règles de sécurité et de conduite que l’on énonce en début de soirée.

Communication : atteindre la jauge d’inscription

Cette étape est à prendre au sérieux un mois avant la tenue de l’événement. Il s’agit de maximiser la visibilité de l’événement pour atteindre la jauge maximale établie par le lieu qui accueille l’événement. Pour cela, j’ai eu l’occasion de me doter de plusieurs méthodes :

Être le plus exhaustif possible dans la description de l’événement (date, lieu, horaires, programme, sponsors, visuels, etc.)
Créer du contenu régulier sur les réseaux sociaux pour rappeler la date de l’événement et les modalités d’inscription (LinkedIn majoritaire, Twitter par le passé)
Solliciter les participants de l’événement pour qu’ils partagent l’événement sur leurs réseaux sociaux ou leurs réseaux d’entreprise
Informer la communauté française avec la liste de diffusion pgsql-fr-generale pour toucher un public plus large, voire donner envie à d’autres groupes de se lancer dans l’organisation de Meetup (qui sait ?)

Identité visuelle (optionnelle)

Au cours des derniers mois, nous avons travaillé avec Yoann, la refonte de l’identité visuelle du groupe Meetup avec un nouveau logo et une nouvelle charte graphique. C’est cosmétique, mais cela permet de donner une image plus professionnelle et une identité forte au sein des communautés lilloises existantes. Nous espérons nous faire une petite place et une petite notoriété dans le paysage local.

Pour avoir délégué par deux fois la création de la vignette de l’événement, je recommande de travailler avec un graphiste ou un designer pour obtenir un résultat professionnel et soigné. En attendant qu’un des membres qui m’entoure soit suffisamment qualifié, on fait avec les moyens du bord.

Enfin, et c’était notre petite fierté de l’année, nous nous sommes dotées d’un logo Slonik, la mascotte de PostgreSQL. La démarche de création s’est appuyée énormément sur les nouveaux outils de génération par intelligences artificielles, et nous avons été bluffés par la qualité du résultat. Un grand merci à Isaac pour son aide précieuse dans les retouches et les ajustements du logo.

Remerciements

Au cours de cette conférence, j’ai eu l’occasion de remercier un tas de monde. En particulier, les membres de l’association PostgreSQL France, pour leur confiance qu’ils nous ont accordée, Matthieu Cornillon et moi-même, d’avoir accepté notre dossier de candidature pour le choix de la ville de Lille cette année 2024.

Un des slides de ma présentation était dédié à toutes les entreprises qui ont accueilli nos rencontres, et qui, sans le savoir, m’ont permis d’ajuster le format et le contenu de nos Meetups. Un grand merci à elles pour leur sympathie et leur accueil chaleureux. C’était également l’opportunité de mettre en avant les intervenants et les intervenantes qui ont accepté de partager leur expérience et leur expertise lors des Meetup PostgreSQL Lille. Un grand merci à elles et à eux d’avoir vécu l’aventure avec moi !

Enfin, j’ai été heureux que ce retour d’expérience puisse faire écho à quelques personnes dans la salle, qui m’ont félicité pour le travail accompli et m’ont informé de leur intention de se lancer dans l’organisation de Meetup dans leur propre ville. C’est une belle récompense pour moi, et cela me donne envie de poursuivre mon engagement et de donner l’exemple pour la promotion de PostgreSQL en France.