Ce chapitre décrit la syntaxe de SQL. Il donne les fondements pour comprendre les chapitres suivants qui iront plus en détail sur la façon dont les commandes SQL sont appliquées pour définir et modifier des données.
Nous avertissons aussi nos utilisateurs, déjà familiers avec le SQL, qu'ils doivent lire ce chapitre très attentivement car il existe plusieurs règles et concepts implémentés différemment suivant les bases de données SQL ou spécifiques à PostgreSQL™.
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 identifieur, un identifieur entre guillemets, un littéral (ou 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).
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.
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).
La syntaxe SQL n'est pas très cohérente en ce qui concerne les jetons identifieurs des commandes et 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 dans une certaine position, et cette variante particulière de 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, « Référence ».
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'identifieurs. 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 identifieurs ont la même structure lexicale, signifiant que quelqu'un ne peut pas savoir si un jeton est un identifieur ou un mot clé sans connaître le langage. Une liste complète des mots clé est disponible dans l'Annexe C, Mots-clé SQL.
Les identifieurs 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 identifieur 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'identifieur suivant 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 identifieurs de cette forme sont sûr de passer les conflits possibles avec les futures extensions du standard.
Le système utilise au plus NAMEDATALEN-1 octets d'un identifieur ; les noms longs peuvent être écrits dans des commandes mais ils seront tronqués. Par défaut, NAMEDATALEN vaut 64. Du coup, la taille maximum de l'identifieur 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.
L'identifieur et les noms de mots clés 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'identifieur : l'identifieur délimité ou l'identifieur entre guillemets. Il est formé en englobant une séquence arbitraire de caractères entre des guillemets doubles ("). Un identifieur délimité est toujours un identifieur, 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 identifieurs entre guillemets comme ceci :
UPDATE "ma_table" SET "a" = 5;
Les identifieurs 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 possible autrement, comme des noms contenant des espaces ou des arobases. La limitation de la longueur s'applique toujours.
Une variante des identifiants entre guillemets permet d'inclure des caractères Unicode échappés en les identifiant par leur code. Cette variante commence par U& (U en majuscule ou minuscule suivi par un « et ») 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'identifiant "data" peut être écrit ainsi :
U&"d\0061t\+000061"
L'exemple suivant, moisn 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 en litéral dans l'identifiant, é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.
Mettre un identifieur entre guillemets le rend sensible à la casse alors que les noms sans guillemets sont toujours convertis en minuscules. Par exemple, les identifieurs 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 ('), c'est-à-dire '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 au 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 d'« échappement » 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 (\) comme une séquence type C d'échappement d'antislash avec laquelle la combinaison d'antislash et du (ou des) caractère(s) suivant représente une valeur spéciale, comme indiqué dans Tableau 4.1, « Séquences d'échappements d'antislash ».
Tableau 4.1. Séquences d'échappements d'antislash
| Séquence d'échappement d'antislash | Interprétation |
|---|---|
| \b | suppression |
| \f | retour en début de ligne |
| \n | saut de ligne |
| \r | saut de ligne |
| \t | tabulation |
| \o, \oo, \ooo (o = 0 - 7) | valeur octale |
| \xh, \xhh (h = 0 - 9, A - F) | valeur hexadécimale |
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'octet que vous créez soient des caractères valides dans l'encodage du jeu de caractères du serveur. Quand l'encodage est UTF-8, alors la syntaxe d'échappement alternatif de l'Unicode, expliqué dans Section 4.1.2.3, « Constantes de chaînes avec des échappements Unicode », doit être utilisé à la place. (L'alternative serait de faire l'encodage UTF-8 manuellement et d'écrire les octets, ce qui serait très complexe.)
![[Attention]](images/caution.png)
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. Ceci est nécessaire pour la compatibilité ascendante avec le comportement historique pour lequel les échappements à base d'antislash étaient toujours reconnus. Bien que standard_conforming_strings est désactivée par défaut, cette valeur par défaut vaudra on dans une prochaine version pour améliorer le respect des standards. Du coup, la migration des applications vers un meilleur espect des standards est fortement conseillé. Si vous avez besoin d'utiliser un échappement antislash pour représenter un caractère spécial, écrivez la constante avec un E pour vous assurer qu'elle sera bien gérée dans les prochaines versions.
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 ê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 ») 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'identifiant '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 guillement 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.
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 ou d'antislashs 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$
Ici, la séquence $q$[\t\r\n\v\\]$q$ représente une chaîne littérale avec guillemet dollar [\t\r\n\v\\], qui sera reconnu 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 identifieur doit en être séparé par un espace blanc ; sinon, le délimiteur du guillemet dollar serait pris comme faisant parti de l'identifieur 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 littérales 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 standards 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.
Autrement, les constantes de chaînes de bits peuvent ê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 :
chiffres chiffres.[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'exponentiel (e), s'il est présent. Il peut ne 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 forcément 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 contenant soit un point décimal soit 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 poins 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écifiques 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 arbitrary peut être saisie en utilisant une des notations suivantes :
type 'chaîne' 'chaîne'::type CAST ( 'chaîne' AS type )
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, « Conversions de type » 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, « Conversions de type ». Pour éviter une ambiguïté syntaxique, la syntaxe type 'chaîne' peut seulement être utilisée pour spécifier le type d'une constante littérale. Une autre restriction sur la syntaxe type 'chaîne' est qu'il ne fonctionne pas pour les types de tableau ; utilisez :: 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 une généralisation du standard : SQL spécifie cette syntaxe uniquement pour quelques types de données mais PostgreSQL™ l'autorise pour tous les types. La syntaxe :: 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 celui 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 identifieur 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 fixée d'une commande SQL particulière.
Les crochets ([]) sont utilisés pour sélectionner les éléments d'un tableau. Voir la Section 8.14, « Tableaux » 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 identifieur entre guillemets.
Le caractère deux points (:) est utilisé pour sélectionner des « morceaux » de tableaux (voir la Section 8.14, « Tableaux »). Dans certains dialectes SQL (tel que le SQL embarqué), il est utilisé pour préfixer les noms de variable.
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 par 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, « Précédence des opérateurs (en ordre décroissant) » 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. Ceci pourrait conduire à un comportement non intuitif ; par exemple, les opérateurs booléens < et > ont une précédence différente des opérateurs booléens <= et >=. De même, vous aurez quelque fois 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 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 (en ordre décroissant)
| 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 | négation unaire |
| ^ | gauche | exposant |
| * / % | gauche | multiplication, division, modulo |
| + - | gauche | addition, soustraction |
| IS | IS TRUE, IS FALSE, IS UNKNOWN, IS NULL | |
| ISNULL | test pour NULL | |
| NOTNULL | test pour non NULL | |
| (autres) | gauche | tout autre opérateur natif et défini par l'utilisateur |
| IN | appartenance à un ensemble | |
| BETWEEN | compris entre | |
| OVERLAPS | surcharge un intervalle de temps | |
| LIKE ILIKE SIMILAR | correspondance de modèles de chaînes | |
| < > | inférieur, supérieur à | |
| = | droite | égalité, affectation |
| 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 votre.
Lorsqu'un nom d'opérateur qualifié par un schéma est utilisé dans la syntaxe OPERATOR, comme par exemple 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, « Précédence des opérateurs (en ordre décroissant) » pour les opérateurs « autres ». Ceci est vrai quelque soit le nom spécifique de l'opérateur apparaissant à l'intérieur de OPERATOR().
Langage SQL