4. Syntaxe SQL
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™.
4.1. Structure lexicale
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 ».
4.1.1. Identifieurs et mots clés
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 caractères 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.
Si cette limite est problématique, elle peut être élevée en
modifiant NAMEDATALEN dans src/include/postgres_ext.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.
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.
4.1.2.1. Constantes de
chaînes
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.
\b est un antislash, \f est un « form
feed », \n est un retour à
la ligne, \r est un retour chariot,
\t est une tabulation. Sont aussi
supportés \
chiffres
, où
chiffres
représente la valeur
octale d'un octet et \x
chiffreshexa
, où
chiffreshexa
représentela valeur
hexadécimale d'un octet. (C'est de votre responsabilité de vous
assurer que les séquences d'octets créées sont des caractères
valides dans le codage du jeu de caractères du serveur.) 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 ''.
Attention
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.
4.1.2.2. Constantes
de chaînes avec guillemet dollar
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.
4.1.2.3. Constantes de
chaînes de bits
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.
4.1.2.4. Constantes numériques
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.
4.1.2.5. Constantes
d'autres types
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.8,
« 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.8,
« Conversions de type ». Mais, la forme
type
'
chaîne
' peut
seulement être utilisée pour spécifier le type d'une constante
littérale. Une autre restriction sur
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.
4.1.4. Caractères spéciaux
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.10,
« 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.10,
« 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.
4.1.5. Commentaires
Un commentaire est une séquence arbitraire 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.
4.1.6. Précédence lexicale
Le
Tableau 4.1, « 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.1. 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
|
exponentiel
|
|
*
/
%
|
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.1, « 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().
|