Une entrée SQL consiste en une séquence de commandes. Une commande est composée d'une séquence de jetons, terminés par un point-virgule (« ; »). La fin du flux en entrée termine aussi une commande. Les jetons valides dépendent de la syntaxe particulière de la commande.
Un jeton peut être un mot-clé, un identificateur, un identificateur entre guillemets, une constante ou un symbole de caractère spécial. Les jetons sont normalement séparés par des espaces blancs (espace, tabulation, nouvelle ligne), mais n'ont pas besoin de l'être s'il n'y a pas d'ambiguïté (ce qui est seulement le cas si un caractère spécial est adjacent à des jetons d'autres types).
Par exemple, ce qui suit est (syntaxiquement) valide pour une entrée SQL :
SELECT * FROM MA_TABLE; UPDATE MA_TABLE SET A = 5; INSERT INTO MA_TABLE VALUES (3, 'salut ici');
C'est une séquence de trois commandes, une par ligne (bien que cela ne soit pas requis , plusieurs commandes peuvent se trouver sur une même ligne et une commande peut se répartir sur plusieurs lignes).
De plus, des commentaires peuvent se trouver dans l'entrée SQL. Ce ne sont pas des jetons, ils sont réellement équivalents à un espace blanc.
La syntaxe SQL n'est pas très cohérente en ce qui concerne les jetons
identificateurs des commandes, lesquels sont des opérandes ou des
paramètres. Les premiers jetons sont généralement le nom de la commande.
Dans l'exemple ci-dessus, nous parlons d'une commande « SELECT »,
d'une commande « UPDATE » et d'une commande « INSERT ».
Mais en fait, la commande UPDATE requiert toujours un
jeton SET apparaissant à une certaine position, et cette
variante particulière d'INSERT requiert aussi un
VALUES pour être complète. Les règles précises de syntaxe
pour chaque commande sont décrites dans la Partie VI.
Les jetons tels que SELECT, UPDATE ou
VALUES dans l'exemple ci-dessus sont des exemples de
mots-clés, c'est-à-dire des mots qui ont une
signification dans le langage SQL. Les jetons MA_TABLE et
A sont des exemples d'identificateurs.
Ils identifient des noms de tables, colonnes ou d'autres objets de la base
de données, suivant la commande qui a été utilisée. Du coup, ils sont
quelques fois simplement nommés des « noms ». Les mots-clés et
les identificateurs ont la même structure lexicale, signifiant que quelqu'un
ne peut pas savoir si un jeton est un identificateur ou un mot-clé sans
connaître le langage. Une liste complète des mots-clés est disponible dans
l'Annexe C.
Les identificateurs et les mots-clés SQL doivent commencer avec une lettre
(a-z, mais aussi des lettres de
marques diacritiques différentes et des lettres non latines) ou un tiret bas
(_). Les caractères suivants dans un identificateur ou
dans un mot-clé peuvent être des lettres, des tirets bas, des chiffres
(0-9) ou des signes dollar
($). Notez que les signes dollar ne sont pas autorisés
en tant qu'identificateur d'après le standard SQL, donc leur utilisation
pourrait rendre les applications moins portables. Le standard SQL ne
définira pas un mot-clé contenant des chiffres ou commençant ou finissant
par un tiret bas, donc les identificateurs de cette forme sont sûrs de ne
pas entrer en conflit avec les futures extensions du standard.
Le système utilise au plus NAMEDATALEN-1 octets d'un
identificateur ; les noms longs peuvent être écrits dans des commandes,
mais ils seront tronqués. Par défaut, NAMEDATALEN vaut 64.
Du coup, la taille maximale de l'identificateur est de 63 octets. Si cette
limite est problématique, elle peut être élevée en modifiant
NAMEDATALEN dans
src/include/pg_config_manual.h.
Les mots-clés et les identificateurs sans guillemets doubles sont insensibles à la casse. Du coup :
UPDATE MA_TABLE SET A = 5;
peut aussi s'écrire de cette façon :
uPDaTE ma_TabLE SeT a = 5;
Une convention couramment utilisée revient à écrire les mots-clés en majuscule et les noms en minuscule, c'est-à-dire :
UPDATE ma_table SET a = 5;
Voici un deuxième type d'identificateur : l'identificateur
délimité ou l'identificateur entre
guillemets. Il est formé en englobant une séquence arbitraire de
caractères entre des guillemets doubles ("). Un
identificateur délimité est toujours un identificateur, jamais un mot-clé.
Donc, "select" pourrait être utilisé pour faire référence
à une colonne ou à une table nommée « select », alors qu'un
select sans guillemets sera pris pour un mot-clé et, du
coup, pourrait provoquer une erreur d'analyse lorsqu'il est utilisé alors
qu'un nom de table ou de colonne est attendu. L'exemple peut être écrit avec
des identificateurs entre guillemets comme ceci :
UPDATE "ma_table" SET "a" = 5;
Les identificateurs entre guillemets peuvent contenir tout caractère autre que celui de code 0. (Pour inclure un guillemet double, écrivez deux guillemets doubles.) Ceci permet la construction de noms de tables et de colonnes qui ne seraient pas possibles autrement, comme des noms contenant des espaces ou des arobases. La limitation de la longueur s'applique toujours.
Une variante des identificateurs entre guillemets permet d'inclure des
caractères Unicode échappés en les identifiant par leur point de code.
Cette variante commence par U& (U en majuscule ou
minuscule suivi par un « et commercial ») immédiatement suivis par un
guillemet double d'ouverture, sans espace entre eux. Par exemple
U&"foo". (Notez que c'est source d'ambiguïté avec
l'opérateur &. Utilisez les espaces autour de
l'opérateur pour éviter ce problème.) À l'intérieur des guillemets, les
caractères Unicode peuvent être indiqués dans une forme échappée en écrivant
un antislash suivi par le code hexadécimal sur quatre chiffres ou, autre
possibilité, un antislash suivi du signe plus suivi d'un code hexadécimal
sur six chiffres. Par exemple, l'identificateur "data"
peut être écrit ainsi :
U&"d\0061t\+000061"
L'exemple suivant, moins trivial, écrit le mot russe « slon » (éléphant) en lettres cyrilliques :
U&"\0441\043B\043E\043D"
Si un caractère d'échappement autre que l'antislash est désiré, il peut
être indiqué en utilisant la clause UESCAPE
après la chaîne. Par
exemple :
U&"d!0061t!+000061" UESCAPE '!'
La chaîne d'échappement peut être tout caractère simple autre qu'un chiffre hexadécimal, le signe plus, un guillemet simple ou double, ou un espace blanc. Notez que le caractère d'échappement est écrit entre guillemets simples, pas entre guillemets doubles.
Pour inclure le caractère d'échappement dans l'identificateur sans interprétation, écrivez-le deux fois.
La syntaxe d'échappement Unicode fonctionne seulement quand l'encodage
serveur est UTF8. Quand d'autres encodages clients sont
utilisés, seuls les codes dans l'échelle ASCII (jusqu'à
\007F) peuvent être utilisés. La forme sur quatre
chiffres et la forme sur six chiffres peuvent être utilisées pour indiquer
des paires UTF-16, composant ainsi des caractères comprenant des points de
code plus grands que U+FFFF (et ce, bien que la disponibilité de la forme
sur six chiffres ne le nécessite pas techniquement). (Les paires de
substitution ne sont pas stockées directement, mais combinées dans un point
de code seul qui est ensuite encodé en UTF-8.)
Mettre un identificateur entre guillemets le rend sensible à la casse alors
que les noms sans guillemets sont toujours convertis en minuscules. Par
exemple, les identificateurs FOO, foo
et "foo" sont considérés identiques par
PostgreSQL, mais "Foo" et
"FOO" sont différents des trois autres et entre eux. La
mise en minuscule des noms sans guillemets avec
PostgreSQL n'est pas compatible avec le standard
SQL qui indique que les noms sans guillemets devraient être mis en
majuscule. Du coup, foo devrait être équivalent à
"FOO" et non pas à "foo" en respect
avec le standard. Si vous voulez écrire des applications portables, nous
vous conseillons de toujours mettre entre guillemets un nom particulier ou
de ne jamais le mettre.
Il existe trois types implicites de constantes dans PostgreSQL : les chaînes, les chaînes de bits et les nombres. Les constantes peuvent aussi être spécifiées avec des types explicites, ce qui peut activer des représentations plus précises et gérées plus efficacement par le système. Les constantes implicites sont décrites ci-dessous ; ces constantes sont discutées dans les sous-sections suivantes.
Une constante de type chaîne en SQL est une séquence arbitraire de
caractères entourée par des guillemets simples ('), par
exemple 'Ceci est une chaîne'. Pour inclure un guillemet
simple dans une chaîne constante, saisissez deux guillemets simples
adjacents, par exemple 'Le cheval d''Anne'. Notez que ce
n'est pas identique à un guillemet double
(").
Deux constantes de type chaîne séparées par un espace blanc avec au moins une nouvelle ligne sont concaténées et traitées réellement comme si la chaîne avait été écrite dans une constante. Par exemple :
SELECT 'foo' 'bar';
est équivalent à :
SELECT 'foobar';
mais :
SELECT 'foo' 'bar';
n'a pas une syntaxe valide (ce comportement légèrement bizarre est spécifié par le standard SQL ; PostgreSQL suit le standard).
PostgreSQL accepte aussi les constantes de
chaîne utilisant des échappements qui sont une extension au standard SQL.
Une constante de type chaîne d'échappement est indiquée en écrivant la
lettre E (en majuscule ou minuscule) juste avant le
guillemet d'ouverture, par exemple E'foo'. (Pour
continuer une constante de ce type sur plusieurs lignes, écrire
E seulement avant le premier guillemet d'ouverture.)
À l'intérieur d'une chaîne d'échappement, un caractère antislash
(\) est géré comme une séquence d'échappement
avec antislash du langage C. La combinaison d'antislash et du
(ou des) caractère(s) suivant(s) représente une valeur spéciale, comme indiqué
dans le Tableau 4.1.
Tableau 4.1. Séquences d'échappements avec antislash
| Séquence d'échappement avec antislash | Interprétation |
|---|---|
\b | suppression |
\f | retour en début de ligne |
\n | saut de ligne |
\r | saut de ligne |
\t | tabulation |
\,
\,
\
(o = 0 - 7)
| valeur octale |
\x,
\x
(h = 0 - 9, A - F)
| valeur hexadécimale |
\u,
\U
(x = 0 - 9, A - F)
| caractère Unicode hexadécimal sur 16 ou 32 bits |
Tout autre caractère suivi d'un antislash est pris littéralement. Du coup,
pour inclure un caractère antislash, écrivez deux antislashs
(\\). De plus, un guillemet simple peut être inclus dans
une chaîne d'échappement en écrivant \', en plus de la
façon normale ''.
Il est de votre responsabilité que les séquences d'octets que vous créez, tout spécialement lorsque vous utilisez les échappements octaux et hexadécimaux, soient des caractères valides dans l'encodage du jeu de caractères du serveur. Quand l'encodage est UTF-8, alors les échappements Unicode ou l'autre syntaxe d'échappement Unicode, expliqués dans la Section 4.1.2.3, devraient être utilisés. (L'alternative serait de réaliser l'encodage UTF-8 manuellement et d'écrire les octets, ce qui serait très lourd.)
La syntaxe d'échappement Unicode fonctionne complètement, mais seulement
quand l'encodage du serveur est justement UTF8. Lorsque
d'autres encodages serveur sont utilisés, seuls les points de code dans
l'échelle ASCII (jusqu'à \u007F) peuvent être utilisés.
La forme sur quatre chiffres et la forme sur six chiffres peuvent être
utilisées pour indiquer des paires UTF-16 composant ainsi des caractères
comprenant des points de code plus grands que U+FFFF, et ce bien que la
disponibilité de la forme sur six chiffres ne le nécessite pas
techniquement. (Quand des paires de substitution sont utilisées et que
l'encodage du serveur est UTF8, elles sont tout d'abord
combinées en un point code seul qui est ensuite encodé en UTF-8.)
Si le paramètre de configuration standard_conforming_strings est désactivé
(off), alors PostgreSQL
reconnaît les échappements antislashs dans les constantes traditionnelles
de type chaînes et celles échappées. Néanmoins, à partir de
PostgreSQL 9.1, la valeur par défaut est
on, ce qui signifie que les échappements par antislash
ne sont reconnus que dans les constantes de chaînes d'échappement. Ce
comportement est plus proche du standard SQL, mais pourrait causer des
problèmes aux applications qui se basent sur le comportement historique où
les échappements par antislash étaient toujours reconnus. Pour contourner
ce problème, vous pouvez configurer ce paramètre à off,
bien qu'il soit préférable de ne plus utiliser les échappements par
antislash. Si vous avez besoin d'un échappement par antislash pour
représenter un caractère spécial, écrivez la chaîne fixe avec un
E.
En plus de standard_conforming_strings, les paramètres
de configuration escape_string_warning et backslash_quote imposent le traitement des antislashs dans
les constantes de type chaîne.
Le caractère de code zéro ne peut pas être placé dans une constante de type chaîne.
PostgreSQL supporte aussi un autre type de
syntaxe d'échappement pour les chaînes qui permettent d'indiquer des
caractères Unicode arbitraires par code. Une constante de chaîne
d'échappement Unicode commence avec U& (U en
majuscule ou minuscule suivi par un « et commercial ») immédiatement suivi
par un guillemet double d'ouverture, sans espace entre eux. Par exemple
U&"foo". (Notez que c'est source d'ambiguïté avec
l'opérateur &. Utilisez les espaces autour de
l'opérateur pour éviter ce problème.) À l'intérieur des guillemets, les
caractères Unicode peuvent être indiqués dans une forme échappée en
écrivant un antislash suivi par le code hexadécimal sur quatre chiffres
ou, autre possibilité, un antislash suivi du signe plus suivi d'un code
hexadécimal sur six chiffres. Par exemple, l'identificateur
'data' peut être écrit ainsi :
U&'d\0061t\+000061'
L'exemple suivant, moins trivial, écrit le mot russe « slon » (éléphant) en lettres cyrilliques :
U&'\0441\043B\043E\043D'
Si un caractère d'échappement autre que l'antislash est souhaité, il peut
être indiqué en utilisant la clause UESCAPE
après la chaîne. Par
exemple :
U&'d!0061t!+000061' UESCAPE '!'
Le caractère d'échappement peut être tout caractère simple autre qu'un chiffre hexadécimal, le signe plus, un guillemet simple ou double, ou un espace blanc.
La syntaxe d'échappement Unicode fonctionne seulement quand l'encodage du
serveur est UTF8. Quand d'autres encodages de serveur
sont utilisés, seuls les codes dans l'échelle ASCII (jusqu'à
\007F) peuvent être utilisés.
La forme sur quatre chiffres et la forme sur six chiffres peuvent être
utilisées pour indiquer des paires de substitution UTF-16, composant ainsi
des caractères comprenant des points de code plus grands que U+FFFF (et
ce, bien que la disponibilité de la forme sur six chiffres ne le nécessite
pas techniquement). (Quand des paires de substitution sont utilisées avec
un encodage serveur UTF8, elles sont tout d'abord
combinées en un seul point de code, qui est ensuite encodé en UTF-8.)
De plus, la syntaxe d'échappement de l'Unicode pour les constantes de chaînes fonctionne seulement quand le paramètre de configuration standard_conforming_strings est activé. Dans le cas contraire, cette syntaxe est confuse pour les clients qui analysent les instructions SQL, au point que cela pourrait amener des injections SQL et des problèmes de sécurité similaires. Si le paramètre est désactivé, cette syntaxe sera rejetée avec un message d'erreur.
Pour inclure le caractère d'échappement littéralement dans la chaîne, écrivez-le deux fois.
Alors que la syntaxe standard pour la spécification des constantes de
chaînes est généralement agréable, elle peut être difficile à comprendre
quand la chaîne désirée contient un grand nombre de guillemets simples
car chacun d'entre eux doit être doublé. Pour permettre la
saisie de requêtes plus lisibles dans de telles situations,
PostgreSQL fournit une autre façon, appelée
« guillemet dollar », pour écrire des constantes de chaînes.
Une constante de chaîne avec guillemet dollar consiste en un signe
dollar ($), une « balise » optionnelle
de zéro ou plus de caractères, un autre signe dollar, une séquence
arbitraire de caractères qui constitue le contenu de la chaîne, un signe
dollar, la même balise et un signe dollar. Par exemple, voici deux façons
de spécifier la chaîne « Le cheval d'Anne » en utilisant les
guillemets dollar :
$$Le cheval d'Anne$$ $UneBalise$Le cheval d'Anne$UneBalise$
Notez qu'à l'intérieur de la chaîne avec guillemet dollar, les guillemets simples peuvent être utilisés sans devoir être échappés. En fait, aucun caractère à l'intérieur d'une chaîne avec guillemet dollar n'a besoin d'être échappé : le contenu est toujours écrit littéralement. Les antislashs ne sont pas spéciaux, pas plus que les signes dollar, sauf s'ils font partie d'une séquence correspondant à la balise ouvrante.
Il est possible d'imbriquer les constantes de chaînes avec guillemets dollar en utilisant différentes balises pour chaque niveau d'imbrication. Ceci est habituellement utilisé lors de l'écriture de définition de fonctions. Par exemple :
$fonction$ BEGIN RETURN ($1 ~ $q$[\t\r\n\v\\]$q$); END; $fonction$
Dans cet exemple, la séquence $q$[\t\r\n\v\\]$q$
représente une chaîne constante avec guillemet dollar
[\t\r\n\v\\], qui sera reconnue quand le corps de la
fonction est exécuté par PostgreSQL. Mais
comme la séquence ne correspond pas au délimiteur
$fonction$, il s'agit juste de quelques caractères à
l'intérieur de la constante pour ce qu'en sait la chaîne externe.
La balise d'une chaîne avec guillemets dollar, si elle existe, suit les
mêmes règles qu'un identificateur sans guillemets, sauf qu'il ne peut
pas contenir de signes dollar. Les balises sont sensibles à la casse,
du coup $balise$Contenu de la chaîne$balise$ est
correct, mais $BALISE$Contenu de la chaîne$balise$ ne
l'est pas.
Une chaîne avec guillemets dollar suivant un mot clé ou un identificateur doit en être séparée par un espace blanc ; sinon, le délimiteur du guillemet dollar serait pris comme faisant partie de l'identificateur précédent.
Le guillemet dollar ne fait pas partie du standard SQL, mais c'est un moyen bien plus agréable pour écrire des chaînes constantes que d'utiliser la syntaxe des guillemets simples, bien que compatible avec le standard. Elle est particulièrement utile pour représenter des constantes de type chaîne à l'intérieur d'autres constantes, comme cela est souvent le cas avec les définitions de fonctions. Avec la syntaxe des guillemets simples, chaque antislash dans l'exemple précédent devrait avoir été écrit avec quatre antislashs, ce qui sera réduit à deux antislashs dans l'analyse de la constante originale, puis à un lorsque la constante interne est analysée de nouveau lors de l'exécution de la fonction.
Les constantes de chaînes de bits ressemblent aux constantes de chaînes
standard avec un B (majuscule ou minuscule) juste
avant le guillemet du début (sans espace blanc), c'est-à-dire
B'1001'. Les seuls caractères autorisés dans les
constantes de type chaîne de bits sont 0 et
1.
Les constantes de chaînes de bits peuvent aussi être spécifiées en
notation hexadécimale en utilisant un X avant (minuscule
ou majuscule), c'est-à-dire X'1FF'. Cette notation est
équivalente à une constante de chaîne de bits avec quatre chiffres binaires
pour chaque chiffre hexadécimal.
Les deux formes de constantes de chaînes de bits peuvent être continuées sur plusieurs lignes de la même façon que les constantes de chaînes habituelles. Le guillemet dollar ne peut pas être utilisé dans une constante de chaîne de bits.
Les constantes numériques sont acceptées dans ces formes générales :
chiffreschiffres.[chiffres][e[+-]chiffres] [chiffres].chiffres[e[+-]chiffres]chiffrese[+-]chiffres
où chiffres est un ou plusieurs chiffres
décimaux (de 0 à 9). Au moins un chiffre doit être avant ou après le point
décimal, s'il est utilisé. Au moins un chiffre doit suivre l'indicateur
d'exponentielle (e), s'il est présent. Il ne peut pas
y avoir d'espaces ou d'autres caractères imbriqués dans la constante. Notez
que tout signe plus ou moins en avant n'est pas considéré comme faisant
part de la constante ; il est un opérateur appliqué à la constante.
Voici quelques exemples de constantes numériques valides :
42
3.5
4.
.001
5e2
1.925e-3
Une constante numérique ne contenant ni un point décimal ni un exposant est
tout d'abord présumée du type integer si sa valeur est
contenue dans le type integer (32 bits) ; sinon, il est
présumé de type bigint si sa valeur entre dans un type
bigint (64 bits) ; sinon, il est pris pour un type
numeric. Les constantes contenant des points décimaux et/ou des
exposants sont toujours présumées de type numeric.
Le type de données affecté initialement à une constante numérique est
seulement un point de départ pour les algorithmes de résolution de types.
Dans la plupart des cas, la constante sera automatiquement convertie dans
le type le plus approprié suivant le contexte. Si nécessaire, vous pouvez
forcer l'interprétation d'une valeur numérique sur un type de données
spécifique en la convertissant. Par exemple, vous pouvez forcer une valeur
numérique à être traitée comme un type real
(float4) en écrivant :
REAL '1.23' -- style chaîne 1.23::REAL -- style PostgreSQL (historique)
Ce sont en fait des cas spéciaux des notations de conversion générales discutées après.
Une constante de type arbitraire peut être saisie en utilisant une des notations suivantes :
type'chaîne' 'chaîne'::typeCAST ( 'chaîne' AStype)
Le texte de la chaîne constante est passé dans la routine de conversion
pour le type appelé type. Le résultat est une
constante du type indiqué. La conversion explicite de type peut être omise
s'il n'y a pas d'ambiguïté sur le type de la constante (par exemple,
lorsqu'elle est affectée directement à une colonne de la table), auquel
cas elle est convertie automatiquement.
La constante chaîne peut être écrite en utilisant soit la notation SQL standard soit les guillemets dollar.
Il est aussi possible de spécifier une conversion de type en utilisant une syntaxe style fonction :
nom_type( 'chaîne' )
mais tous les noms de type ne peuvent pas être utilisés ainsi ; voir la Section 4.2.9 pour plus de détails.
Les syntaxes ::, CAST() et d'appels
de fonctions sont aussi utilisables pour spécifier les conversions de
type à l'exécution d'expressions arbitraires, comme discuté dans la Section 4.2.9. Pour éviter une ambiguïté syntaxique,
la syntaxe type
'chaîne'type
'chaîne':: ou
CAST() pour spécifier le type d'une constante de type
tableau.
La syntaxe de CAST() est conforme au standard SQL. La
syntaxe type
'chaine':: est un usage historique dans
PostgreSQL, comme l'est la syntaxe d'appel de
fonction.
Un nom d'opérateur est une séquence d'au plus NAMEDATALEN-1
(63 par défaut) caractères provenant de la liste suivante :
+ - * / < > = ~ ! @ # % ^ & | ` ?
Néanmoins, il existe quelques restrictions sur les noms d'opérateurs :
-- et /* ne peuvent pas apparaître
quelque part dans un nom d'opérateur, car ils seront pris pour le début
d'un commentaire.
Un nom d'opérateur à plusieurs caractères ne peut pas finir avec
+ ou -, sauf si le nom contient
aussi un de ces caractères :
~ ! @ # % ^ & | ` ?
Par exemple, @- est un nom d'opérateur autorisé, mais
*- ne l'est pas. Cette restriction permet à
PostgreSQL d'analyser des requêtes compatibles
avec SQL sans requérir des espaces entre les jetons.
Lors d'un travail avec des noms d'opérateurs ne faisant pas partie du
standard SQL, vous aurez habituellement besoin de séparer les opérateurs
adjacents avec des espaces pour éviter toute ambiguïté. Par exemple, si
vous avez défini un opérateur unaire gauche nommé @,
vous ne pouvez pas écrire X*@Y ; vous devez écrire
X* @Y pour vous assurer que
PostgreSQL le lit comme deux noms d'opérateurs,
et non pas comme un seul.
Quelques caractères non alphanumériques ont une signification spéciale, différente de celle d'un opérateur. Les détails sur leur utilisation sont disponibles à l'endroit où l'élément de syntaxe respectif est décrit. Cette section existe seulement pour avertir de leur existence et pour résumer le but de ces caractères.
Un signe dollar ($) suivi de chiffres est utilisé pour
représenter un paramètre de position dans le corps de la définition d'une
fonction ou d'une instruction préparée. Dans d'autres contextes, le signe
dollar pourrait faire partie d'un identificateur ou d'une constante de
type chaîne utilisant le dollar comme guillemet.
Les parenthèses (()) ont leur signification habituelle
pour grouper leurs expressions et renforcer la précédence. Dans certains
cas, les parenthèses sont requises, car faisant partie de la syntaxe d'une
commande SQL particulière.
Les crochets ([]) sont utilisés pour sélectionner les
éléments d'un tableau. Voir la Section 8.15 pour plus
d'informations sur les tableaux.
Les virgules (,) sont utilisées dans quelques
constructions syntaxiques pour séparer les éléments d'une liste.
Le point-virgule (;) termine une commande SQL. Il ne
peut pas apparaître quelque part dans une commande, sauf à l'intérieur
d'une constante de type chaîne ou d'un identificateur entre guillemets.
Le caractère deux points (:) est utilisé pour
sélectionner des « morceaux » de tableaux (voir la Section 8.15). Dans certains dialectes SQL (tel que le SQL embarqué),
il est utilisé pour préfixer les noms de variables.
L'astérisque (*) est utilisé dans certains contextes
pour indiquer tous les champs de la ligne d'une table ou d'une valeur
composite. Elle a aussi une signification spéciale lorsqu'elle est
utilisée comme argument d'une fonction d'agrégat. Cela signifie que
l'agrégat ne requiert pas de paramètre explicite.
Le point (.) est utilisé dans les constantes numériques
et pour séparer les noms de schéma, table et colonne.
Un commentaire est une séquence de caractères commençant avec deux tirets et s'étendant jusqu'à la fin de la ligne, par exemple :
-- Ceci est un commentaire standard en SQL
Autrement, les blocs de commentaires style C peuvent être utilisés :
/* commentaires multilignes * et imbriqués: /* bloc de commentaire imbriqué */ */
où le commentaire commence avec /* et s'étend jusqu'à
l'occurrence de */. Ces blocs de commentaires
s'imbriquent, comme spécifié dans le standard SQL, mais pas comme dans le
langage C. De ce fait, vous pouvez commenter des blocs importants de code
pouvant contenir des blocs de commentaires déjà existants.
Un commentaire est supprimé du flux en entrée avant une analyse plus poussée de la syntaxe et est remplacé par un espace blanc.
Le Tableau 4.2 affiche la précédence et l'associativité des opérateurs dans PostgreSQL. La plupart des opérateurs ont la même précédence et sont associatifs par la gauche. La précédence et l'associativité des opérateurs sont codées en dur dans l'analyseur.
De même, vous aurez quelquefois besoin d'ajouter des parenthèses lors de l'utilisation de combinaisons d'opérateurs binaires et unaires. Par exemple :
SELECT 5 ! - 6;
sera analysé comme :
SELECT 5 ! (- 6);
parce que l'analyseur n'a aucune idée, jusqu'à ce qu'il ne soit trop tard,
que ! est défini comme un opérateur suffixe, et non pas
préfixe. Pour obtenir le comportement désiré dans ce cas, vous devez
écrire :
SELECT (5 !) - 6;
C'est le prix à payer pour l'extensibilité.
Tableau 4.2. Précédence des opérateurs (du plus haut vers le plus bas)
| Opérateur/Élément | Associativité | Description |
|---|---|---|
. | gauche | séparateur de noms de table et de colonne |
:: | gauche | conversion de type, style PostgreSQL |
[ ] | gauche | sélection d'un élément d'un tableau |
+ - | droite | plus unaire, moins unaire |
^ | gauche | exposant |
* / % | gauche | multiplication, division, modulo |
+ - | gauche | addition, soustraction |
| (autres opérateurs) | gauche | tout autre opérateur natif ou défini par l'utilisateur |
BETWEEN IN LIKE ILIKE SIMILAR | intervalle contenu, recherche d'appartenance, correspondance de chaîne | |
< > = <= >= <>
| opérateurs de comparaison | |
IS ISNULL NOTNULL | IS TRUE, IS FALSE, IS
NULL, IS DISTINCT FROM, etc | |
NOT | droite | négation logique |
AND | gauche | conjonction logique |
OR | gauche | disjonction logique |
Notez que les règles de précédence des opérateurs s'appliquent aussi aux opérateurs définis par l'utilisateur qui ont le même nom que les opérateurs internes mentionnés ici. Par exemple, si vous définissez un opérateur « + » pour un type de données personnalisé, il aura la même précédence que l'opérateur interne « + », peu importe ce que fait le vôtre.
Lorsqu'un nom d'opérateur qualifié par un schéma est utilisé dans la syntaxe
OPERATOR, comme dans :
SELECT 3 OPERATOR(pg_catalog.+) 4;
la construction OPERATOR est prise pour avoir la
précédence par défaut affichée dans le Tableau 4.2
pour les opérateurs « autres ». Ceci est vrai, quel que soit le nom
spécifique de l'opérateur apparaissant à l'intérieur de
OPERATOR().
Les versions de PostgreSQL antérieures à la
9.5 utilisaient des règles de précédence différentes pour les opérateurs.
En particulier, <= >= et
<> étaient traités comme des opérateurs
génériques ; les tests IS avaient une priorité
supérieure ; NOT BETWEEN et les constructions qui
en découlent agissaient de façon incohérente, ayant dans certains cas la
précédence de NOT plutôt que de
BETWEEN. Ces règles étaient modifiées pour un meilleur
accord avec le standard SQL et pour réduire la configuration d'un
traitement incohérent de constructions équivalentes logiquement. Dans la
plupart des cas, ces changements ne résulteront pas en un changement de
comportement. Il peut arriver que des échecs du type « opérateur
inconnu » surviennent, auquel cas un ajout de parenthèses devrait
corriger le problème. Néanmoins, il existe des cas particuliers où une
requête pourrait voir son comportement changé sans qu'une erreur
d'analyse soit renvoyée. Si vous êtes inquiet qu'un de ces changements
puisse avoir cassé quelque chose silencieusement, vous pouvez tester
votre application en activant le paramètre operator_precedence_warning pour voir si des messages
d'avertissement sont tracés.