Présentation du graph SQL/PGQ

PostgreSQL 19 beta 3, publié le 13 août 2026, implémente la partie property‑graph du standard SQL:2023, désignée SQL/PGQ. La syntaxe 

CREATE PROPERTY GRAPH social
    VERTEX TABLES (
        person KEY (id) LABEL person PROPERTIES (id, name)
    )
    EDGE TABLES (
        follows KEY (follower, followee)
            SOURCE KEY (follower) REFERENCES person (id)
            DESTINATION KEY (followee) REFERENCES person (id)
            LABEL follows
    );
crée un objet de type vue qui associe les lignes de la table person aux sommets et les lignes de follows aux arêtes. Aucun stockage supplémentaire n’est généré ; le graphe repose exclusivement sur les tables existantes. Les requêtes utilisent GRAPH_TABLE avec une notation de pattern matching : 
SELECT * FROM GRAPH_TABLE (social
    MATCH (a IS person)-[IS follows]->(b IS person)
    COLUMNS (a.name AS follower, b.name AS followee)
) ORDER BY follower, followee;
Le plan d’exécution affiché montre que le moteur transforme la requête en un plan relationnel classique (hash join, scans séquentiels). Ainsi, les statistiques, les index et le coût estimé restent ceux du planur PostgreSQL habituel, garantissant une compatibilité totale avec les optimisations existantes. La principale contrainte actuelle est l’absence de chemins de longueur variable : les quantificateurs de type {1,3} sont acceptés syntaxiquement mais rejetés à l’exécution, obligeant l’utilisateur à expliciter chaque saut.

Mécanisme de la clause FOR PORTION OF

La nouvelle clause FOR PORTION OF s’applique aux colonnes de type range et permet de modifier ou supprimer une sous‑période sans toucher le reste du tuple. Dans l’exemple fourni, la table price contient une ligne couvrant toute l’année 2026 : 

UPDATE price
    FOR PORTION OF valid_at FROM '2026-07-01' TO '2026-08-01'
    SET amount = 7.99;
La mise à jour découpe la ligne originale en trois : la période antérieure, la période mise à jour et la période postérieure. Le résultat montre trois lignes distinctes, chacune conservant la même clé sku mais avec des intervalles [2026-01-01,2026-07-01), [2026-07-01,2026-08-01) et [2026-08-01,2027-01-01). La même logique s’applique à la suppression : 
DELETE FROM price
    FOR PORTION OF valid_at FROM '2026-12-01' TO NULL;
supprime la tranche finale en la « trimmant », laissant la partie antérieure intacte. Cette fonctionnalité s’inscrit dans le nouveau chapitre de documentation dédié aux tables temporelles, offrant une manipulation atomique des intervalles sans recourir à des déclencheurs ou à des requêtes de réécriture manuelle.

Nouvelle instruction ON CONFLICT DO SELECT

Jusqu’à présent, INSERT … ON CONFLICT DO NOTHING … RETURNING ne renvoyait que les lignes réellement insérées, rendant impossible la différenciation entre « déjà présent » et « non inséré ». PostgreSQL 19 ajoute ON CONFLICT DO SELECT, qui renvoie les lignes conflictuelles sans les modifier. Exemple : 

INSERT INTO inventory VALUES ('widget', 1), ('gadget', 3)
    ON CONFLICT (sku) DO SELECT
    RETURNING *;
retourne la ligne existante pour widget tout en insérant gadget. Cette instruction évite le recours à DO UPDATE lorsqu’on ne souhaite pas toucher les enregistrements déjà présents, réduisant ainsi le nombre d’écritures et le risque de contention sur les index uniques.

Implications et limites

Les ajouts de PostgreSQL 19 sont purement syntaxiques : aucune nouvelle couche d’exécution n’est introduite, ce qui préserve les performances établies mais impose aux développeurs de connaître les limites du moteur actuel, notamment l’absence de chemins de longueur variable dans les graphes. La clause FOR PORTION OF simplifie la gestion des données temporelles, mais elle repose sur le type range et nécessite que les tables soient déjà conçues avec des colonnes de ce type. Enfin, ON CONFLICT DO SELECT améliore la lisibilité du code d’insertion, tout en conservant le même modèle de verrouillage que DO UPDATE, ce qui signifie que les scénarios de haute concurrence doivent rester vigilants quant aux conflits d’index. En combinant ces trois innovations, PostgreSQL 19 propose des outils plus expressifs sans sacrifier la stabilité du planificateur éprouvé.