Les expressions rationnelles de PostgreSQL sont implantées à l'aide d'un paquetage écrit par Henry Spencer. Une grande partie de la description des expressions rationnelles ci-dessous est une copie intégrale de son manuel.

Les expressions rationnelles (ERs), telles que définies dans POSIX 1003.2, existent sous deux formes : les ER étendues ou ERE (en gros celles de egrep) et les ER basiques ou ERB (BRE en anglais) (en gros celles d'ed). PostgreSQL supporte les deux formes et y ajoute quelques extensions ne faisant pas partie du standard POSIX, mais largement utilisées du fait de leur disponibilité dans les langages de programmation tels que Perl et Tcl. Les ER qui utilisent ces extensions non POSIX sont appelées des ER avancées ou ERA (ARE en anglais) dans cette documentation. Les ERA sont un surensemble exact des ERE alors que les ERB ont des incompatibilités de notation (sans parler du fait qu'elles sont bien plus limitées). En premier lieu sont décrits les formats ERA et ERE, en précisant les fonctionnalités qui ne s'appliquent qu'aux ERA. L'explication des différences des ERB vient ensuite.

Une expression rationnelle est définie par une ou plusieurs branches séparées par des caractères |. Elle établit une correspondance avec tout ce qui correspond à une des branches.

Une branche contient des atomes quantifiés, ou contraintes, concaténés. Elle établit une correspondance pour le premier, suivi d'une correspondance pour le second, etc. ; une branche vide établit une correspondance avec une chaîne vide.

Un atome quantifié est un atome éventuellement suivi d'un quantificateur unique. Sans quantificateur, il établit une correspondance avec l'atome. Avec un quantificateur, il peut établir un certain nombre de correspondances avec l'atome. Un atome est une des possibilités du Tableau 9.16. Les quantificateurs possibles et leurs significations sont disponibles dans le Tableau 9.17.

Une contrainte établit une correspondance avec une chaîne vide, mais cette correspondance n'est établie que lorsque des conditions spécifiques sont remplies. Une contrainte peut être utilisée là où un atome peut l'être et ne peut pas être suivie d'un quantificateur. Les contraintes simples sont affichées dans le Tableau 9.18 ; quelques contraintes supplémentaires sont décrites plus loin.

Une ER ne peut pas se terminer par un antislash (\).

Les formes qui utilisent {...} sont appelées limites. Les nombres m et n à l'intérieur d'une limite sont des entiers non signés dont les valeurs vont de 0 à 255 inclus.

Les quantificateurs non gourmands (disponibles uniquement avec les ERA) correspondent aux mêmes possibilités que leurs équivalents normaux (gourmand), mais préfèrent le plus petit nombre de correspondances au plus grand nombre. Voir la Section 9.7.3.5 pour plus de détails.

Les contraintes « lookahead » et « lookbehind » ne doivent pas contenir de références arrières (voir la Section 9.7.3.3), et toutes les parenthèses contenues sont considérées comme non capturantes.

Une expression entre crochets est une liste de caractères contenue dans []. Une correspondance est habituellement établie avec tout caractère de la liste (voir cependant plus bas). Si la liste débute par ^, la correspondance est établie avec tout caractère non compris dans la liste. Si deux caractères de la liste sont séparés par un tiret (-), il s'agit d'un raccourci pour représenter tous les caractères compris entre ces deux-là, c'est-à-dire qu'en ASCII, [0-9] correspond à tout chiffre. Deux séquences ne peuvent pas partager une limite, par exemple a-c-e. Les plages étant fortement liées à la séquence de tri (collate), il est recommandé de ne pas les utiliser dans les programmes portables.

Un ] peut être inclus dans la liste s'il en est le premier caractère (éventuellement précédé de ^). Un - peut être inclus dans la liste s'il en est le premier ou le dernier caractère ou s'il est la deuxième borne d'une plage. Un - peut être utilisé comme première borne d'une plage s'il est entouré par [. et .] et devient de ce fait un élément d'interclassement (collating element). À l'exception de ces caractères, des combinaisons utilisant [ (voir les paragraphes suivants) et des échappements (uniquement pour les ERA), tous les autres caractères spéciaux perdent leur signification spéciale à l'intérieur d'une expression entre crochets. En particulier, \ n'est pas spécial lorsqu'il suit les règles des ERE ou des ERB bien qu'il soit spécial (en tant qu'introduction d'un échappement) dans les ERA.

Dans une expression entre crochets, un élément d'interclassement (un caractère, une séquence de caractères multiples qui s'interclasse comme un élément unique, ou le nom d'une séquence d'interclassement) entouré de [. et .] représente la séquence de caractères de cet élément d'interclassement. La séquence est un élément unique de la liste dans l'expression entre crochets. Une expression entre crochets contenant un élément d'interclassement multicaractères peut donc correspondre à plusieurs caractères (par exemple, si la séquence d'interclassement inclut un élément d'interclassement ch, alors l'ER [[.ch.]]*c établit une correspondance avec les cinq premiers caractères de chchcc.

Dans une expression entre crochets, un élément d'interclassement écrit entre [= et =] est une classe d'équivalence qui représente les séquences de caractères de tous les éléments d'interclassement équivalents à celui-là, lui compris. (En l'absence d'élément d'interclassement équivalent, le traitement correspond à celui obtenu avec les délimiteurs [. et .]). Par exemple, si o et ^ sont les membres d'une classe d'équivalence, alors [[=o=]], [[=^=]] et [o^] sont tous synonymes. Une classe d'équivalence ne peut pas être borne d'une plage.

Dans une expression entre crochets, le nom d'une classe de caractères écrit entre [: et :] représente la liste de tous les caractères appartenant à cette classe. Une classe de caractères ne peut pas être utilisé comme point final d'un intervalle. Le standard POSIX définit les noms suivants de classe de caractères : alnum (lettres et chiffres), alpha (lettres), blank (espace et tabulation), cntrl (caractères de contrôle), digit (chiffres), graph (caractères affichables sauf l'espace), lower (lettres en minuscule), print (caractères affichables avec l'espace), punct (ponctuation), space (tout espace blanc), upper (lettres en majuscules) et xdigit (chiffres hexadécimaux). Le comportement de classes de caractères standards est généralement cohérent parmi les différentes plateformes en ce qui concerne les ensembles ASCII 7 bits. Qu'un caractère non-ASCII soit considéré comme appartenant à une de ces classes dépend du collationnement utilisé pour la fonction ou l'opérateur d'expression rationnelle (voir Section 23.2), ou par défaut à la configuration du LC_CTYPE de la base de données (voir Section 23.1). La classification des caractères non-ASCII peut varier entre les plateformes même dans des locales nommées de façon similaire. (La locale C ne considère jamais les caractères non-ASCII comme appartenant à une de ces classes.) En plus de ces classes de caractères standards, PostgreSQL définit la classe de caractères ASCII, contenant exactement l'ensemble ASCII 7 bits.

Il existe deux cas spéciaux d'expressions entre crochets : les expressions entre crochets [[:<:]] et [[:>:]] sont des contraintes, qui établissent une correspondance avec des chaînes vides respectivement au début et à la fin d'un mot. Un mot est défini comme une séquence de caractères de mot qui n'est ni précédée ni suivie de caractères de mot. Un caractère de mot est un caractère alnum (comme défini par la classe de caractères POSIX décrite ci-dessus) ou un tiret bas. C'est une extension, compatible avec, mais non spécifiée dans POSIX 1003.2, et devant être utilisée avec précaution dans les logiciels conçus pour être portables sur d'autres systèmes. Les échappements de contraintes décrits ci-dessous sont généralement préférables (ils ne sont pas plus standard, mais certainement plus simples à saisir).

Les échappements sont des séquences spéciales débutant avec \ suivi d'un caractère alphanumérique. Il existe plusieurs sortes d'échappements : entrée de caractère, raccourci de classe, échappement de contraintes et rétroréférences. Un \ suivi d'un caractère alphanumérique qui ne constitue pas un échappement valide est illégal dans une ERA. Pour les ERE, il n'y pas d'échappement : en dehors d'une expression entre crochets, un \ suivi d'un caractère alphanumérique représente simplement ce caractère (comme ordinaire) et, à l'intérieur d'une expression entre crochets, \ est un caractère ordinaire. (C'est dans ce dernier cas que se situe réellement l'incompatibilité entre les ERE et les ERA.)

Les échappements de caractère (character-entry escapes) permettent d'indiquer des caractères non affichables et donc indésirables dans les ER. Ils sont présentés dans le Tableau 9.19.

Les échappements de raccourci de classe (class-shorthand escapes) fournissent des raccourcis pour certaines classes de caractères communément utilisées. Ils sont présentés dans le Tableau 9.20.

Un échappement de contrainte (constraint escape) est une contrainte, qui correspond à la chaîne vide sous certaines conditions, écrite comme un échappement. Ces échappements sont présentés dans le Tableau 9.21.

Une rétroréférence (back reference) (\n) correspond à la même chaîne que la sous-expression entre parenthèses précédente indiquée par le nombre n (voir le Tableau 9.22). Par exemple, ([bc])\1 peut correspondre à bb ou cc, mais ni à bc ni à cb. La sous-expression doit précéder complètement la référence dans l'ER. Les sous-expressions sont numérotées dans l'ordre des parenthèses ouvrantes. Les parenthèses non capturantes ne définissent pas de sous-expressions.

Les chiffres hexadécimaux sont 0-9, a-f et A-F. Les chiffres octaux sont 0-7.

Les échappements numériques de saisie de caractères spécifiant des valeurs hors de l'intervalle ASCII (0-127) ont des significations dépendant de l'encodage de la base de données. Quand l'encodage est UTF-8, les valeurs d'échappement sont équivalents aux codes Unicode. Par exemple, \u1234 correspond au caractère U+1234. Pour d'autres encodages multioctets, les échappements de saisie de caractères spécifient uniquement la concaténation des valeurs d'octet pour le caractère. Si la valeur d'échappement ne correspond pas à un caractère légal dans l'encodage de la base de données, aucune erreur ne sera levée, mais cela ne correspondra à aucune donnée.

Les échappements de caractère sont toujours pris comme des caractères ordinaires. Par exemple, \135 est ] en ASCII, mais \135 ne termine pas une expression entre crochets.

Dans les expressions entre crochets, \d, \s, et \w perdent leurs crochets externes et \D, \S et \W ne sont pas autorisés. (Ainsi, [a-c\d] est équivalent à [a-c[:digit:]]. Mais [a-c\D], qui est équivalent à [a-c^[:digit:]], est interdit.)

Un mot est défini selon suivant la spécification de [[:<:]] et [[:>:]] donnée ci-dessus. Les échappements de contrainte sont interdits dans les expressions entre crochets.

En plus de la syntaxe principale décrite ci-dessus, il existe quelques formes spéciales et autres possibilités syntaxiques.

Une ER peut commencer avec un des deux préfixes director spéciaux. Si une ER commence par ***:, le reste de l'ER est considéré comme une ERA. (Ceci n'a normalement aucun effet dans PostgreSQL, car les ER sont supposées être des ERA, mais il a un effet si le mode ERE ou BRE a été spécifié par le paramètre flags à une fonction d'expression rationnelle.) Si une ER commence par ***=, le reste de l'ER est considéré comme une chaîne littérale, tous les caractères étant considérés ordinaires.

Une ERA peut commencer par des options intégrées : une séquence (?xyz) (où xyz correspond à un ou plusieurs caractères alphabétiques) spécifie les options affectant le reste de l'ER. Ces options surchargent toutes les options précédemment déterminées -- en particulier, elles peuvent surcharger le comportement sur la sensibilité à la casse d'un opérateur d'une ER ou le paramètre flags vers une fonction d'expression rationnelle. Les lettres d'options disponibles sont indiquées dans le Tableau 9.23. Notez que ces mêmes lettres d'option sont utilisées dans les paramètres flags des fonctions d'expressions rationnelles.

Les options intégrées prennent effet à la ) qui termine la séquence. Elles ne peuvent apparaître qu'au début d'une ERA (après le directeur ***: s'il y en a un).

En plus de la syntaxe habituelle d'une ER (compacte), dans laquelle tous les caractères ont une signification, il existe une syntaxe étendue, accessible en signifiant l'option intégrée x. Avec la syntaxe étendue, les caractères espace dans l'ER sont ignorés comme le sont tous les caractères entre un # et le retour chariot qui suit (ou la fin de l'ER). Ceci permet de mettre en paragraphe et de commenter une ER complexe. Il existe trois exceptions à cette règle de base :

Pour cela, les caractères espace sont l'espace, la tabulation, le retour chariot et tout caractère appartenant à la classe de caractère space.

Enfin, dans une ERA, en dehors d'expressions entre crochets, la séquence (?#ttt) (où ttt est tout texte ne contenant pas )) est un commentaire, totalement ignoré. Là encore, cela n'est pas permis entre les caractères des symboles multicaractères comme (?:. De tels commentaires sont plus un artefact historique qu'une fonctionnalité utile et leur utilisation est obsolète ; on utilise plutôt la syntaxe étendue.

Aucune de ces extensions métasyntaxiques n'est disponible si un directeur initial ***= indique que la saisie utilisateur doit être traitée comme une chaîne littérale plutôt que comme une ER.

Dans l'hypothèse où une ER peut correspondre à plusieurs sous-chaînes d'une chaîne donnée, l'ER correspond à celle qui apparaît la première dans la chaîne. Si l'ER peut correspondre à plusieurs sous-chaînes à partir de ce point, c'est soit la correspondance la plus longue possible, soit la correspondance la plus courte possible, qui est retenue selon que l'ER est gourmande ou non gourmande (greedy/non-greedy).

La gourmandise d'une ER est déterminée par les règles suivantes :

Les règles ci-dessus associent les attributs de gourmandise non seulement avec les atomes quantifiés individuels, mais aussi avec les branches et les ER complètes qui contiennent des atomes quantifiés. Cela signifie que la correspondance est établie de sorte que la branche, ou l'ER complète, corresponde à la sous-chaîne la plus longue ou la plus courte possible comme un tout. Une fois la longueur de la correspondance complète déterminée, la partie de cette correspondance qui établit une correspondance avec une sous-expression particulière est déterminée sur la base de l'attribut de gourmandise de cette sous-expression, priorité étant donnée aux sous-expressions commençant le plus tôt dans l'ER.

Exemple de signification de tout cela :

SELECT SUBSTRING('XY1234Z', 'Y*([0-9]{1,3})');
Résultat : 123
SELECT SUBSTRING('XY1234Z', 'Y*?([0-9]{1,3})');
Résultat : 1

Dans le premier cas, l'ER dans son intégralité est gourmande parce que Y* est gourmand. Il peut établir une correspondance qui débute à Y et correspondre à la chaîne la plus longue à partir de là, soit Y123. La sortie reprend la partie entre parenthèses, soit 123. Dans le second cas, l'ER dans son ensemble n'est pas gourmande, car Y*? ne l'est pas. Il peut établir une correspondance qui débute à Y et correspond à la chaîne la plus courte à partir de là, soit Y1. La sous-expression [0-9]{1,3} est gourmande, mais elle ne peut pas changer la décision sur la longueur totale de la correspondance ; elle ne peut donc correspondre qu'à 1.

En résumé, quand une ER contient à la fois des sous-expressions gourmandes et non gourmandes, la longueur de la correspondance totale est soit aussi longue que possible, soit aussi courte que possible, en fonction de l'attribut affecté à l'ER complète. Les attributs assignés aux sous-expressions permettent uniquement de déterminer la partie de la correspondance qu'elles peuvent incorporer les unes par rapport aux autres.

Les quantificateurs {1,1} et {1,1}? peuvent être utilisés pour forcer, respectivement, la préférence la plus longue (gourmandise) ou la plus courte (retenue), sur une sous-expression ou une ER complète. Ceci est utile quand vous avez besoin que l'expression complète ait une gourmandise différente de celle déduite de son élément. Par exemple, supposons que nous essayons de séparer une chaîne contenant certains chiffres en les chiffres et les parties avant et après. Nous pourrions le faire ainsi :

SELECT regexp_match('abc01234xyz', '(.*)(\d+)(.*)');
Résultat : {abc0123,4,xyz}
  

Cela ne fonctionne pas : le premier .* est tellement gourmand qu'il « mange » tout ce qu'il peut, laissant \d+ correspondre à la dernière place possible, à savoir le dernier chiffre. Nous pouvons essayer de corriger cela en lui demandant un peu de retenue :

SELECT regexp_match('abc01234xyz', '(.*?)(\d+)(.*)');
Résultat : {abc,0,""}
  

Ceci ne fonctionne pas plus parce que, maintenant, l'expression entière se retient fortement et, du coup, elle termine la correspondance dès que possible. Nous obtenons ce que nous voulons en forçant l'expression entière à être gourmande :

SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
Résultat : {abc,01234,xyz}
  

Contrôler la gourmandise de l'expression séparément de ses composants donne une plus grande flexibilité dans la gestion des motifs à longueur variable.

Lors de la décision de ce qu'est une correspondance longue ou courte, les longueurs de correspondance sont mesurées en caractères et non pas en éléments d'interclassement. Une chaîne vide est considérée comme plus grande que pas de correspondance du tout. Par exemple : bb* correspond aux trois caractères du milieu de abbbc ; (week|wee)(night|knights) correspond aux dix caractères de weeknights ; lorsqu'une correspondance est recherchée entre (.*).* et abc, la sous-expression entre parenthèses correspond aux trois caractères ; et lorsqu'une correspondance est recherchée entre (a*)* et bc, à la fois l'ER et la sous-expression entre parenthèses correspondent à une chaîne vide.

Lorsqu'il est précisé que la recherche de correspondance ne tient pas compte de la casse, cela revient à considérer que toutes les distinctions de casse ont disparu de l'alphabet. Quand un caractère alphabétique, pour lequel existent différentes casses, apparaît comme un caractère ordinaire en dehors d'une expression entre crochets, il est en fait transformé en une expression entre crochets contenant les deux casses, c'est-à-dire que x devient [xX]. Quand il apparaît dans une expression entre crochets, toutes les transformations de casse sont ajoutées à l'expression entre crochets, c'est-à-dire que [x] devient [xX] et que [^x] devient [^xX].

Si la sensibilité aux retours chariot est précisée, . et les expressions entre crochets utilisant ^ n'établissent jamais de correspondance avec le caractère de retour à la ligne (de cette façon, les correspondances ne franchissent jamais les retours chariot, sauf si l'ER l'explicite), et ^ et $ établissent une correspondance avec la chaîne vide, respectivement après et avant un retour chariot, en plus d'établir une correspondance respectivement au début et à la fin de la chaîne. Mais les échappements d'ERA \A et \Z n'établissent toujours de correspondance qu'au début ou à la fin de la chaîne.

Si une sensibilité partielle aux retours chariot est indiquée, cela affecte . et les expressions entre crochets, comme avec la sensibilité aux retours chariot, mais pas ^ et $.

Si une sensibilité partielle inverse aux retours chariot est indiquée, cela affecte ^ et $, comme avec la sensibilité aux retours chariot, mais pas . et les sous-expressions. Ceci n'est pas très utile, mais est toutefois fourni pour des raisons de symétrie.

Aucune limite particulière n'est imposée sur la longueur des ER dans cette implantation. Néanmoins, les programmes prévus pour être portables ne devraient pas employer d'ER de plus de 256 octets, car une implantation POSIX peut refuser d'accepter de telles ER.

La seule fonctionnalité des ERA qui soit incompatible avec les ERE POSIX est le maintien de la signification spéciale de \ dans les expressions entre crochets. Toutes les autres fonctionnalités ERA utilisent une syntaxe interdite, à effets indéfinis ou non spécifiés dans les ERE POSIX ; la syntaxe *** des directeurs ne figure pas dans la syntaxe POSIX pour les ERB et les ERE.

Un grand nombre d'extensions ERA sont empruntées à Perl, mais certaines ont été modifiées et quelques extensions Perl ne sont pas présentes. Les incompatibilités incluent \b, \B, le manque de traitement spécial pour le retour à la ligne en fin de chaîne, l'ajout d'expressions entre crochets aux expressions affectées par les correspondances avec retour à la ligne, les restrictions sur les parenthèses et les références arrière dans les contraintes lookahead/lookbehind et la sémantique de correspondance chaînes les plus longues/les plus courtes (au lieu de la première rencontrée).

Deux incompatibilités importantes existent entre les syntaxes ERA et ERE reconnues par les versions antérieures à PostgreSQL 7.4 :

Les ERB diffèrent des ERE par plusieurs aspects. Dans les BRE, |, + et ? sont des caractères ordinaires et il n'existe pas d'équivalent pour leur fonctionnalité. Les délimiteurs de frontières sont \{ et \}, avec { et } étant eux-mêmes des caractères ordinaires. Les parenthèses pour les sous-expressions imbriquées sont \( et \), ( et ) restent des caractères ordinaires. ^ est un caractère ordinaire, sauf au début d'une ER ou au début d'une sous-expression entre parenthèses, $ est un caractère ordinaire sauf à la fin d'une ER ou à la fin d'une sous-expression entre parenthèses et * est un caractère ordinaire s'il apparaît au début d'une ER ou au début d'une sous-expression entre parenthèses (après un possible ^). Enfin, les rétroréférences à un chiffre sont disponibles, et \< et \> sont des synonymes pour respectivement [[:<:]] et [[:>:]] ; aucun autre échappement n'est disponible dans les BRE.

Depuis SQL:2008, le standard SQL inclut un opérateur LIKE_REGEX qui réalise de la correspondance de motif suivant le standard des expressions rationnelles XQuery. PostgreSQL ne dispose pas encore de cet opérateur, mais vous pouvez obtenir un comportement très similaire en utilisant la fonction regexp_match(), car les expressions rationnelles XQuery sont très proches de la syntaxe ERA décrite ci-dessus.

Les différences notables entre la fonctionnalité existante d'expressions rationnelles basées sur POSIX et les expressions rationnelles XQuery incluent :