Passer au contenu principal

Description

pg_clickhouse est une extension PostgreSQL qui permet d’exécuter des requêtes à distance sur des bases de données ClickHouse, et inclut un foreign data wrapper. Elle est compatible avec PostgreSQL 13 et versions ultérieures, ainsi qu’avec ClickHouse 23 et versions ultérieures.

Prise en main

Le moyen le plus simple de tester pg_clickhouse est d’utiliser l’Docker image, qui contient l’image Docker PostgreSQL standard avec les extensions pg_clickhouse et re2 :
Consultez le tutoriel pour commencer à importer des tables ClickHouse et à déporter l’exécution des requêtes.

Utilisation

Politique de versionnage

pg_clickhouse se conforme au [versionnement sémantique] pour ses versions publiques.
  • La version majeure est incrémentée en cas de modification de l’API
  • La version mineure est incrémentée en cas de modifications SQL rétrocompatibles
  • La version de correctif est incrémentée pour les modifications portant uniquement sur le binaire
Une fois installée, PostgreSQL distingue deux variantes de version :
  • La version de la bibliothèque (définie par PG_MODULE_MAGIC sur PostgreSQL 18 et versions ultérieures) inclut la version sémantique complète, visible dans la sortie de la fonction pgch_version() ou de la fonction Postgres pg_get_loaded_modules().
  • La version de l’extension (définie dans le fichier de contrôle) inclut uniquement les versions majeure et mineure, visibles dans la table pg_catalog.pg_extension, la sortie de la fonction pg_available_extension_versions() et \dx pg_clickhouse.
En pratique, cela signifie qu’une version qui incrémente la version de correctif, par ex. de v0.1.0 à v0.1.1, bénéficie à toutes les bases de données qui ont chargé v0.1 et n’ont pas besoin d’exécuter ALTER EXTENSION pour profiter de la mise à niveau. En revanche, une version qui incrémente la version mineure ou majeure sera accompagnée de scripts de mise à niveau SQL, et toutes les bases de données existantes qui contiennent l’extension doivent exécuter ALTER EXTENSION pg_clickhouse UPDATE pour bénéficier de la mise à niveau.

Référence SQL DDL

Les expressions SQL DDL suivantes utilisent pg_clickhouse.

CREATE EXTENSION

Utilisez CREATE EXTENSION pour ajouter pg_clickhouse à une base de données :
Utilisez WITH SCHEMA pour l’installer dans un schéma spécifique (recommandé) :

ALTER EXTENSION

Utilisez ALTER EXTENSION pour modifier l’extension pg_clickhouse. Exemples :
  • Après l’installation d’une nouvelle version de pg_clickhouse, utilisez la clause UPDATE :
  • Utilisez SET SCHEMA pour déplacer l’extension vers un nouveau schéma :

DROP EXTENSION

Utilisez DROP EXTENSION pour supprimer pg_clickhouse d’une base de données :
Cette commande échoue si des objets dépendent de pg_clickhouse. Utilisez la clause CASCADE pour les supprimer également :

CREATE SERVER

Utilisez CREATE SERVER pour créer un serveur distant connecté à un serveur ClickHouse. Exemple :
Les options prises en charge sont :
  • driver : Le pilote de connexion ClickHouse à utiliser, soit “binary”, soit “http”. Obligatoire.
  • compression : Compression du protocole natif pour le pilote “binary”, parmi “none”, “lz4” ou “zstd”. La valeur par défaut est “lz4”. Ignoré par le pilote “http”.
  • dbname : La base de données ClickHouse à utiliser lors de la connexion. La valeur par défaut est “default”.
  • fetch_size : Taille approximative des lots, en octets, pour le streaming HTTP. Les lots sont découpés sur les limites des lignes. La valeur par défaut est 50000000 (50 MB). 0 désactive le streaming et met en mémoire tampon l’intégralité de la réponse. Les tables étrangères peuvent remplacer cette valeur.
  • host : Le nom d’hôte du serveur ClickHouse. La valeur par défaut est “localhost” ;
  • port : Le port auquel se connecter sur le serveur ClickHouse. Les valeurs par défaut sont les suivantes :
    • 9440 si driver vaut “binary” et que host est un hôte ClickHouse Cloud
    • 9004 si driver vaut “binary” et que host n’est pas un hôte ClickHouse Cloud
    • 8443 si driver vaut “http” et que host est un hôte ClickHouse Cloud
    • 8123 si driver vaut “http” et que host n’est pas un hôte ClickHouse Cloud
  • min_tls_version : Version minimale du protocole TLS à négocier sur les connexions qui utilisent TLS. L’une de TLSv1, TLSv1.1, TLSv1.2 ou TLSv1.3. La valeur par défaut est la version minimale propre à la bibliothèque TLS. S’applique aux deux pilotes.
  • secure : Contrôle l’utilisation de TLS pour la connexion. L’une des valeurs suivantes :
    • auto (par défaut) : utilise TLS lorsque host est un hôte ClickHouse Cloud ou que port est un port sécurisé ; en clair sinon.
    • on (ou true/yes/1) : utilise toujours TLS. La valeur par défaut de port est 8443 (“http”) ou 9440 (“binary”).
    • off (ou false/no/0) : n’utilise jamais TLS. La valeur par défaut de port est 8123 (“http”) ou 9000 (“binary”).

ALTER SERVER

Utilisez ALTER SERVER pour modifier un serveur distant. Exemple :
Les options sont les mêmes que pour CREATE SERVER.

DROP SERVER

Utilisez DROP SERVER pour supprimer un serveur distant :
Cette commande échoue si d’autres objets dépendent du serveur. Utilisez CASCADE pour supprimer également ces objets dépendants :

CREATE USER MAPPING

Utilisez CREATE USER MAPPING pour associer un utilisateur PostgreSQL à un utilisateur ClickHouse. Par exemple, pour associer l’utilisateur PostgreSQL actuel à l’utilisateur ClickHouse distant lors de la connexion au serveur distant taxi_srv :
Les options prises en charge sont :
  • user : Le nom de l’utilisateur ClickHouse. La valeur par défaut est “default”.
  • password : Le mot de passe de l’utilisateur ClickHouse.

ALTER USER MAPPING

Utilisez ALTER USER MAPPING pour modifier la définition d’un mappage d’utilisateur :
Les options sont les mêmes que celles de CREATE USER MAPPING.

DROP USER MAPPING

Utilisez DROP USER MAPPING pour supprimer un mappage d’utilisateur :

IMPORT FOREIGN SCHEMA

Utilisez IMPORT FOREIGN SCHEMA pour importer toutes les tables définies dans une base de données ClickHouse en tant que tables étrangères dans un schéma PostgreSQL :
Utilisez LIMIT TO pour restreindre l’importation à certaines tables :
Utilisez EXCEPT pour exclure des tables :
pg_clickhouse récupère la liste de toutes les tables de la base de données ClickHouse spécifiée (« demo » dans les exemples ci-dessus), récupère la définition des colonnes de chacune d’elles et exécute des commandes CREATE FOREIGN TABLE pour créer les tables étrangères. Les colonnes sont définies à l’aide des types de données pris en charge et, lorsqu’elles sont détectables, des options prises en charge par CREATE FOREIGN TABLE.
Préservation de la casse des identifiants importésIMPORT FOREIGN SCHEMA exécute quote_identifier() sur les noms de table et de colonne qu’il importe, ce qui entoure de guillemets doubles les identifiants contenant des majuscules ou des espaces. Ces noms de table et de colonne doivent donc être entourés de guillemets doubles dans les requêtes PostgreSQL. Les noms entièrement en minuscules et sans espace n’ont pas besoin d’être mis entre guillemets.Par exemple, étant donnée cette table ClickHouse :
IMPORT FOREIGN SCHEMA crée cette table étrangère :
Les requêtes doivent donc utiliser les guillemets de manière appropriée, par exemple :
Pour créer des objets avec des noms différents ou entièrement en minuscules (et donc insensibles à la casse), utilisez CREATE FOREIGN TABLE.

CREATE FOREIGN TABLE

Utilisez CREATE FOREIGN TABLE pour créer une table étrangère permettant d’interroger les données d’une base de données ClickHouse :
Les options de table prises en charge sont :
  • database : Le nom de la base de données distante. Par défaut, il s’agit de la base de données définie pour le serveur distant.
  • fetch_size : Taille approximative du lot en octets pour HTTP streaming. Remplace la valeur fetch_size au niveau du serveur. La valeur par défaut est 50000000 (50 MB). 0 désactive le streaming et met en tampon l’intégralité de la réponse.
  • table_name : Le nom de la table distante. Par défaut, il s’agit du nom spécifié pour la table distante.
  • engine : Le [moteur de table] utilisé par la table ClickHouse. Pour CollapsingMergeTree() et AggregatingMergeTree(), pg_clickhouse applique automatiquement les paramètres aux expressions de fonction exécutées sur la table.
Utilisez le type de données adapté au type de données ClickHouse distant de chaque colonne. Les options de colonne prises en charge sont :
  • column_name : Le nom de la colonne côté ClickHouse, utilisé de préférence au nom d’attribut PostgreSQL lors de la régénération des requêtes et des insertions. Utile pour faire correspondre des noms de colonnes PostgreSQL non quotés en minuscules à des colonnes ClickHouse sensibles à la casse, par exemple :
  • AggregateFunction : Le nom de la fonction d’agrégation appliquée à une colonne de [type AggregateFunction]. Faites correspondre le type de données au type ClickHouse passé à la fonction et spécifiez le nom de la fonction d’agrégation via l’option de colonne appropriée ; pg_clickhouse ajoutera automatiquement Merge à la fonction d’agrégation qui évalue la colonne.
  • SimpleAggregateFunction : Le nom de la fonction d’agrégation appliquée à une colonne de [type SimpleAggregateFunction]. Faites correspondre le type de données au type ClickHouse passé à la fonction et spécifiez le nom de la fonction d’agrégation via l’option de colonne appropriée.

ALTER FOREIGN TABLE

Utilisez ALTER FOREIGN TABLE pour modifier la définition d’une table étrangère :
Les options de table et de colonne prises en charge sont identiques à celles de CREATE FOREIGN TABLE.

DROP FOREIGN TABLE

Utilisez DROP FOREIGN TABLE pour supprimer une table étrangère :
Cette commande échoue s’il existe des objets dépendant de la table étrangère. Utilisez la clause CASCADE pour les supprimer également :

Référence SQL DML

Les expressions SQL DML ci-dessous peuvent utiliser pg_clickhouse. Les exemples s’appuient sur ces tables ClickHouse :

EXPLAIN

La commande EXPLAIN fonctionne comme prévu, mais l’option VERBOSE provoque l’affichage de la requête ClickHouse “Remote SQL” :
Cette requête est exécutée dans ClickHouse via un nœud de plan “Foreign Scan”, le SQL exécuté à distance.

SELECT

Utilisez l’instruction SELECT pour exécuter des requêtes sur les tables pg_clickhouse, comme sur n’importe quelle autre table :
pg_clickhouse s’efforce de déléguer autant que possible l’exécution des requêtes à ClickHouse, y compris les fonctions d’agrégation. Utilisez EXPLAIN pour déterminer dans quelle mesure le pushdown s’applique. Pour la requête ci-dessus, par exemple, toute l’exécution est déléguée à ClickHouse
pg_clickhouse délègue également les JOIN entre des tables provenant du même serveur distant :
Une jointure avec une table locale générera des requêtes moins efficaces sans un ajustement fin. Dans cet exemple, nous créons une copie locale de la table nodes et effectuons la jointure avec celle-ci plutôt qu’avec la table distante :
Dans ce cas, nous pouvons confier une plus grande part de l’agrégation à ClickHouse en regroupant par node_id plutôt que par la colonne locale, puis en effectuant la jointure avec la table de correspondance plus tard :
Le nœud “Foreign Scan” délègue désormais l’agrégation par node_id, réduisant le nombre de lignes devant être rapatriées dans Postgres de 1000 (la totalité d’entre elles) à seulement 8, une pour chaque nœud.

PREPARE, EXECUTE, DEALLOCATE

À partir de la version v0.1.2, pg_clickhouse prend en charge les requêtes paramétrées, principalement créées par la commande PREPARE :
Utilisez EXECUTE comme d’habitude pour exécuter une requête préparée :
L’exécution paramétrée empêche le pilote « http » de convertir correctement les fuseaux horaires des valeurs DateTime sur les versions de ClickHouse antérieures à 25.8, version dans laquelle le [bogue sous-jacent] a été [corrigé]. Notez que PostgreSQL peut parfois utiliser un plan de requête paramétré même sans PREPARE. Pour toute requête nécessitant une conversion précise des fuseaux horaires, si une mise à niveau vers la version 25.8 ou ultérieure n’est pas possible, utilisez plutôt le pilote « binary ».
pg_clickhouse pousse les agrégations, comme d’habitude, comme on peut le voir dans la sortie EXPLAIN en mode verbose :
Notez qu’il a envoyé les valeurs de date complètes, et non les marqueurs de paramètres. Ceci vaut pour les cinq premières requêtes, comme décrit dans les [notes sur PREPARE] de PostgreSQL. Lors de la sixième exécution, il envoie des [paramètres de requête] ClickHouse au format {param:type} : parameters:
Utilisez DEALLOCATE pour libérer une instruction préparée :

INSERT

Utilisez la commande INSERT pour insérer des valeurs dans une table ClickHouse distante :

COPY

Utilisez la commande COPY pour insérer un lot de lignes dans une table ClickHouse distante :
⚠️ Limitations de l’API Batch pg_clickhouse n’a pas encore implémenté la prise en charge de l’API d’insertion par lot du FDW de PostgreSQL. Par conséquent, COPY utilise actuellement des instructions INSERT pour insérer les enregistrements. Cela sera amélioré dans une prochaine version.

LOAD

Utilisez LOAD pour charger la bibliothèque partagée pg_clickhouse :
Il n’est généralement pas nécessaire d’utiliser LOAD, car Postgres chargera automatiquement pg_clickhouse la première fois que l’une de ses fonctionnalités (fonctions, tables étrangères, etc.) est utilisée. Le seul cas où il peut être utile de LOAD pg_clickhouse est pour SET les paramètres de pg_clickhouse avant d’exécuter des requêtes qui en dépendent.

SET

Utilisez SET pour définir les paramètres de configuration personnalisés de pg_clickhouse.

pg_clickhouse.session_settings

Le paramètre pg_clickhouse.session_settings configure les [paramètre ClickHouse] à appliquer aux requêtes suivantes. Exemple :
Par défaut, la valeur est join_use_nulls 1, group_by_use_nulls 1, final 1. Définissez-la sur une chaîne vide pour utiliser les paramètres du serveur ClickHouse.
La syntaxe est une liste de paires clé/valeur délimitées par des virgules et séparées par un ou plusieurs espaces. Les clés doivent correspondre aux [paramètre ClickHouse]. Faites précéder les espaces, les virgules et les barres obliques inverses dans les valeurs d’une barre oblique inverse :
Ou utilisez des valeurs entre guillemets simples pour éviter d’avoir à échapper les espaces et les virgules ; envisagez d’utiliser le dollar quoting pour éviter d’avoir à utiliser des guillemets doubles :
Si la lisibilité est importante pour vous et que vous devez définir de nombreux paramètres, utilisez plusieurs lignes, par exemple :
Certains paramètres seront ignorés lorsqu’ils risqueraient d’interférer avec le fonctionnement de pg_clickhouse lui-même. Il s’agit des paramètres suivants :
  • date_time_output_format : le pilote « http » exige qu’il soit défini sur “iso”
  • format_tsv_null_representation : le pilote « http » exige la valeur par défaut
  • output_format_tsv_crlf_end_of_line le pilote « http » exige la valeur par défaut
Sinon, pg_clickhouse ne valide pas les paramètres, mais les transmet à ClickHouse pour chaque requête. Il prend donc en charge tous les paramètres de chaque version de ClickHouse. Notez que pg_clickhouse doit être chargé avant de définir pg_clickhouse.session_settings ; utilisez soit le [préchargement de bibliothèque partagée], soit simplement l’un des objets de l’extension pour garantir son chargement.

pg_clickhouse.pushdown_regex

Le paramètre pg_clickhouse.pushdown_regex contrôle si pg_clickhouse déporte les fonctions et les opérateurs d’expressions régulières. C’est le comportement par défaut ; définissez ce paramètre sur false pour éviter qu’ils ne soient déportés :
Voir Expressions régulières pour plus de détails.

ALTER ROLE

Utilisez la commande SET d’ALTER ROLE pour précharger pg_clickhouse et/ou SET ses paramètres pour certains rôles :
Utilisez la commande RESET de ALTER ROLE pour réinitialiser le préchargement de pg_clickhouse et/ou les paramètres :

Préchargement

Si presque toutes les connexions Postgres doivent utiliser pg_clickhouse, envisagez d’utiliser le [préchargement de bibliothèque partagée] pour le charger automatiquement :

session_preload_libraries

Charge la bibliothèque partagée à chaque nouvelle connexion à PostgreSQL :
Utile pour profiter des mises à jour sans redémarrer le serveur : il suffit de se reconnecter. Peut aussi être défini pour des utilisateurs ou des rôles spécifiques via ALTER ROLE.

shared_preload_libraries

Charge la bibliothèque partagée dans le processus parent de PostgreSQL au démarrage :
Utile pour économiser de la mémoire et réduire la surcharge de chargement à chaque session, mais nécessite le redémarrage du cluster lors de la mise à jour de la bibliothèque.

Types de données

pg_clickhouse fait correspondre les types de données ClickHouse suivants aux types de données PostgreSQL. IMPORT FOREIGN SCHEMA utilise le premier type de la colonne PostgreSQL lors de l’importation des colonnes ; des types supplémentaires peuvent être utilisés dans les instructions CREATE FOREIGN TABLE :
ClickHousePostgreSQLNotes
Boolboolean
Datedate
Date32date
DateTimetimestamptz
Decimalnumeric
Float32real
Float64double precision
IPv4inet
IPv6inet
Int16smallint
Int32integer
Int64bigint
Int8smallint
JSONjsonb, json
Stringtext, bytea
UInt16integer
UInt32bigint
UInt64bigintErreur pour les valeurs > max BIGINT
UInt8smallint
UUIDuuid
Des notes et informations complémentaires suivent.

BYTEA

ClickHouse ne fournit pas l’équivalent du type PostgreSQL BYTEA, mais permet de stocker n’importe quels octets dans le type String. En général, les chaînes ClickHouse doivent être associées au type PostgreSQL TEXT, mais pour les données binaires, utilisez BYTEA. Exemple :
Cette dernière requête SELECT produira :
Notez que si les colonnes ClickHouse contiennent des octets nuls, une table étrangère utilisant des colonnes TEXT ne produira pas les valeurs attendues :
Affichera :
Notez que les lignes deux et trois contiennent des valeurs tronquées. En effet, PostgreSQL repose sur des chaînes terminées par un caractère nul et ne prend pas en charge les caractères nuls dans ses chaînes. L’insertion de valeurs binaires dans des colonnes TEXT réussira et fonctionnera comme prévu :
Les colonnes de texte seront correctes :
Mais pas si vous les lisez comme BYTEA :
En règle générale, utilisez les colonnes TEXT uniquement pour les chaînes encodées et les colonnes BYTEA uniquement pour les données binaires, sans jamais passer de l’une à l’autre.

Référence des fonctions et des opérateurs

Fonctions

Ces fonctions constituent l’interface permettant d’interroger une base de données ClickHouse.

clickhouse_raw_query

Se connecte à un service ClickHouse via son interface HTTP, exécute une seule query, puis se déconnecte. Le deuxième argument facultatif indique une chaîne de connexion dont la valeur par défaut est host=localhost port=8123. Les paramètres de connexion pris en charge sont :
  • host : l’hôte auquel se connecter ; obligatoire.
  • port : le port HTTP auquel se connecter ; la valeur par défaut est 8123, sauf si host est un hôte ClickHouse Cloud, auquel cas elle est 8443
  • dbname : le nom de la database à laquelle se connecter.
  • username : le username à utiliser pour la connexion ; la valeur par défaut est default
  • password : le password à utiliser pour l’authentification ; par défaut, aucun mot de passe n’est utilisé
Par défaut, aucun rôle ne dispose de l’accès EXECUTE à cette fonction ; envisagez d’accorder, via GRANT, cet accès uniquement aux rôles qui doivent légitimement exécuter des queries ClickHouse ad hoc, par exemple un admin role ClickHouse dédié : Utile pour les queries qui ne renvoient aucun enregistrement, mais celles qui renvoient des values sont retournées sous la forme d’une seule valeur textuelle :

Fonctions de pushdown

pg_clickhouse applique le pushdown à un sous-ensemble des fonctions intégrées de PostgreSQL utilisées dans les expressions conditionnelles (clauses HAVING et WHERE). Ce sous-ensemble correspond aux équivalents ClickHouse suivants :

Opérateurs de pushdown

Fonctions personnalisées

Ces fonctions personnalisées créées par pg_clickhouse assurent le pushdown des requêtes externes pour certaines fonctions ClickHouse n’ayant pas d’équivalent dans PostgreSQL. Si l’une de ces fonctions ne peut pas être poussée down, elle déclenchera une exception.

Pushdown des extensions

pg_clickhouse reconnaît les fonctions de certaines extensions de base et tierces, et effectue leur pushdown vers leurs équivalents dans ClickHouse.

re2

Toutes les fonctions de l’[extension re2] font l’objet d’un pushdown 1:1 à ClickHouse :

intarray

Une fonction intarray fait l’objet d’un pushdown vers ClickHouse :

fuzzystrmatch

Deux fonctions fuzzystrmatch font l’objet d’un pushdown vers ClickHouse :

Conversions de type avec pushdown

pg_clickhouse prend en charge le pushdown de conversions de type telles que CAST(x AS bigint) pour les types de données compatibles. Pour les types incompatibles, le pushdown échoue ; si x dans cet exemple est un UInt64 de ClickHouse, ClickHouse refusera de convertir la valeur. Pour effectuer le pushdown de conversions vers des types de données incompatibles, pg_clickhouse fournit les fonctions suivantes. Elles lèvent une exception dans PostgreSQL si elles ne sont pas pushed down.

Agrégats en pushdown

Ces fonctions d’agrégation PostgreSQL sont déléguées à ClickHouse via le pushdown.

Agrégats personnalisés

Ces fonctions d’agrégation personnalisées créées par pg_clickhouse assurent le pushdown des requêtes externes pour certaines fonctions d’agrégation ClickHouse sans équivalent dans PostgreSQL. Si l’une de ces fonctions ne peut pas faire l’objet d’un pushdown, une exception sera levée.

Agrégats d’ensemble ordonné en pushdown

Ces [fonctions d’agrégation d’ensemble ordonné] sont associées aux [fonctions d’agrégation paramétriques] de ClickHouse en passant leur argument direct comme paramètre et leurs expressions ORDER BY comme arguments. Par exemple, cette requête PostgreSQL :
Correspond à la requête ClickHouse suivante :
Notez que les suffixes DESC et NULLS FIRST non définis par défaut pour ORDER BY ne sont pas pris en charge et génèrent une erreur.

Fonctions de fenêtre avec pushdown

Ces [fonctions de fenêtre] PostgreSQL peuvent être déléguées à ClickHouse avec des clauses OVER (PARTITION BY ... ORDER BY ...), y compris les spécifications de frame lorsque applicable. Les fonctions de classement (row_number, rank, dense_rank, ntile, cume_dist, percent_rank) omettent leur clause de frame lors du pushdown, car ClickHouse refuse les spécifications de frame pour ces fonctions.

Notes de compatibilité

Expressions régulières

Bien que pg_clickhouse délègue les expressions régulières à leurs équivalents ClickHouse lorsque pg_clickhouse.pushdown_regex vaut true (par défaut), et s’efforce d’assurer un minimum de compatibilité, gardez à l’esprit les différences entre les deux et la manière dont pg_clickhouse les gère.
  • PostgreSQL prend en charge les [expressions régulières POSIX], tandis que ClickHouse prend en charge les expressions régulières RE2. Tenez compte des différences de comportement : utilisez RE2 lorsque l’expression régulière est évaluée par ClickHouse (par exemple, dans une clause WHERE) et POSIX lorsqu’elle est évaluée par Postgres (par exemple, dans une clause SELECT).
  • pg_clickhouse répercute les [options Postgres] en les ajoutant en préfixe à l’expression régulière ClickHouse dans (?). Par exemple :
    Devient
  • Les seules options prises en charge par les deux, et qui peuvent donc être utilisées lorsqu’elles sont évaluées par ClickHouse, sont :
    FlagÉquiv.Remarques
    iicorrespondance insensible à la casse
    mm-s^ et $ correspondent au début/à la fin d’une ligne, en plus du début/de la fin du texte
    nm-salias Postgres de m
    p-sempêche . et [^x] de correspondre à \n
    ssautorise . et [^x] à correspondre à \n
    tsyntaxe stricte, sans effet
    wmcorrespondance partielle inverse sensible aux retours à la ligne
    RE2 ne prend en charge que ces options ; n’utilisez pas d’autres [options Postgres].
  • Ce tableau résume les effets des différents modificateurs (et de l’absence de modificateur, qui revient au même que s) pour la correspondance des sauts de ligne et des fins de ligne. Notez que dans Postgres, m et p empêchent les classes de caractères négatives ([^xyz]) de correspondre à un saut de ligne, alors que les équivalents de ClickHouse ne le font pas. Sinon, les comportements sont les mêmes dans ClickHouse que dans Postgres :
    Motif appliqué à a\nbPostgresClickHouseIdentique ?
    a.btruetrue✔︎
    a[^x]btruetrue✔︎
    a$falsefalse✔︎
    Modificateur s
    (?s)a.btruetrue✔︎
    (?s)a[^x]btruetrue✔︎
    (?s)a$falsefalse✔︎
    Modificateur m
    (?m)a.bfalsefalse✔︎
    (?m)a[^x]btruefalse
    (?m)a$truetrue✔︎
    Modificateur p
    (?p)a.bfalsefalse✔︎
    (?p)a[^x]btruefalse
    (?p)a$falsefalse✔︎
    Modificateur w
    (?w)a.btruetrue
    (?w)a[^x]btruetrue
    (?w)a$truetrue
  • Tout autre flag transmis aux fonctions d’expression régulière empêchera le pushdown de la fonction.
  • L’exception est regexp_replace(), qui prend aussi en charge le flag g. Lorsque g est activé, pg_clickhouse utilise replaceRegexpAll() au lieu de replaceRegexpOne() et supprime le flag avant d’ajouter les autres flags en préfixe.
  • L’argument de remplacement de regexp_replace() dans Postgres prend en charge \& pour désigner la correspondance complète, tandis que ClickHouse utilise \0 pour la correspondance complète. Veillez à utiliser \0 lorsque la fonction fait l’objet d’un pushdown vers ClickHouse.
  • Postgres regexp_match renvoie NULL lorsqu’il n’y a aucune correspondance, tandis que les expressions dont l’exécution est déléguée renvoient un tableau vide. Utilisez COALESCE() pour renvoyer un tableau vide au lieu de NULL afin de comparer les valeurs de retour de manière compatible. Par exemple :
Pour lever toute ambiguïté, envisagez de définir pg_clickhouse.pushdown_regex pour empêcher le pushdown des expressions régulières Postgres vers ClickHouse, et d’utiliser l’ [extension re2], pour laquelle pg_clickhouse prend en charge le pushdown direct des expressions régulières RE2 compatibles avec ClickHouse.

to_char()

Le to_char() de PostgreSQL pour timestamp et timestamp with time zone n’est délégué à ClickHouse formatDateTime que lorsque l’argument de format est une constante de chaîne non-NULL dont chaque mot-clé PostgreSQL a un équivalent ClickHouse strictement identique, octet pour octet. Si le format est dynamique (et non un Const), ou s’il contient un mot-clé ou un modificateur non pris en charge, l’appel retombe sur une évaluation locale dans PostgreSQL — aucun pushdown n’est jamais tenté avec une traduction partielle, de sorte que le résultat reste compatible avec PG. Les formes à deux arguments de to_char() appliquées à numeric, interval et à d’autres types autres que timestamp ne font jamais l’objet d’un pushdown ; ClickHouse formatDateTime ne formate que les valeurs de date et d’heure.

Mots-clés traduits

PostgreSQLClickHouseSignification
YYYY, yyyy%Yannée à 4 chiffres
YY, yy%yannée à 2 chiffres
MM, mm%mmois à 2 chiffres, complété par un zéro à gauche (01–12)
DD, dd%djour du mois à 2 chiffres, complété par un zéro à gauche (01–31)
DDD, ddd%jjour de l’année à 3 chiffres, complété par un zéro à gauche (001–366)
HH24, hh24%Hheure sur 24 heures, complétée par un zéro à gauche (00–23)
HH, hh, HH12, hh12%Iheure sur 12 heures, complétée par un zéro à gauche (01–12)
MI, mi%iminute à 2 chiffres, complétée par un zéro à gauche (00–59)
SS, ss%Sseconde à 2 chiffres, complétée par un zéro à gauche (00–59)
Q, q%Qtrimestre (1–4)
Mon%bnom du mois abrégé, par ex. Oct
Dy%anom du jour de la semaine abrégé, par ex. Mon
AM, PM%pindicateur AM/PM, toujours en majuscules

Texte entre guillemets et littéraux

Le texte placé entre "..." est transmis tel quel, avec chaque % littéral doublé en %% pour échapper au préfixe de spécificateur de ClickHouse. Un \" en dehors des guillemets est également transmis comme un ". À l’intérieur de "...", l’antislash n’échappe que " ; les autres séquences avec antislash sont traitées comme du texte littéral.

Auteurs

David E. Wheeler Copyright (c) 2025-2026, ClickHouse
Dernière modification le 2 juillet 2026