Exigences relatives à l’identificateur

Identificateurs d’objet sans guillemets:

  • Commencent par une lettre (AZ, az) ou un trait de soulignement (« _ »).

  • Ne contiennent que des lettres, des traits de soulignement, des chiffres décimaux (0-9) et des signes dollar ($).

  • Sont stockés et résolus comme des caractères majuscules (par exemple, id est stocké et résolu comme ID).

Si vous mettez des guillemets doubles autour d’un identificateur (par ex. « Mon identificateur avec des blancs et des signes de ponctuation. »), les règles suivantes s’appliquent :

  • La casse de l’identificateur est préservée lors du stockage et de la résolution de l’identificateur (par exemple, "id" est stocké et résolu comme id).

  • L’identificateur peut contenir et commencer par des caractères ASCII, ASCII étendus et non-ASCII.

    Pour utiliser le caractère guillemet double à l’intérieur d’un identificateur cité, utilisez deux guillemets. Par exemple :

    create table "quote""andunquote""" ...
    
    Copy

    crée une table nommée :

    quote"andunquote"
    
    Copy

    où les guillemets font partie du nom.

Note

  • Qu’un identificateur soit avec ou sans guillemets, le nombre maximum de caractères autorisé est de 255 (espaces compris).

  • Les identificateurs peuvent également être spécifiés à l’aide de littéraux de chaînes, de variables de session ou de variables de liaison. Pour plus de détails, voir Variables SQL.

Dans ce chapitre :

Identificateurs sans guillemets

Si un identificateur n’est pas placé entre guillemets doubles, il doit commencer par une lettre ou un trait de soulignement (_) et ne peut pas contenir de caractères étendus ni d’espaces.

Voici des exemples d’identificateurs valides ; toutefois, la casse des caractères de ces identificateurs ne serait pas conservée :

myidentifier
MyIdentifier1
My$identifier
_my_identifier
Copy

Identificateurs entre guillemets doubles

Les identificateurs délimités (c’est-à-dire les identificateurs entourés par des guillemets doubles) sont sensibles à la casse et peuvent commencer par et contenir tous les caractères valides, y compris :

  • Nombres

  • Caractères spéciaux (., ', !, @, #, $, %, ^, &, *, etc.)

  • Caractères ASCII étendus et non ASCII

  • Espaces vides

Par exemple :

"MyIdentifier"
"my.identifier"
"my identifier"
"My 'Identifier'"
"3rd_identifier"
"$Identifier"
"идентификатор"
Copy

Important

Si un objet est créé à l’aide d’un identificateur entre guillemets doubles, lorsqu’il est référencé dans une requête ou toute autre instruction SQL, l’identificateur doit être spécifié exactement tel qu’il a été créé, y compris avec les guillemets doubles. Le fait de ne pas inclure de guillemets peut entraîner une erreur Object does not exist (ou un type d’erreur similaire).

Notez également que l’identificateur complet doit être placé entre guillemets lorsqu’il est référencé dans une requête/instruction SQL. Cela est particulièrement important si des points (.) sont utilisés dans les identificateurs, car ils sont également utilisés dans des noms d’objet pleinement qualifiés pour séparer chaque objet.

Par exemple :

"My.DB"."My.Schema"."Table.1"
Copy

Exceptions

  • Les identificateurs entre guillemets ne sont pas pris en charge pour les noms de fonctions définies par l’utilisateur (UDFs) et de procédures dans lesquelles le langage de gestion est Java, JavaScript, Exécution de scripts Snowflake ou SQL.

  • Vous ne pouvez utiliser que des caractères ASCII pour les noms des fonctions définies par l’utilisateur (UDFs) et des procédures dans lesquelles le langage de gestion est Java.

Résolution de l’identificateur

Par défaut, Snowflake applique les règles suivantes pour stocker les identificateurs (au moment de la création/définition) et les résoudre (dans les requêtes et autres instructions SQL) :

  • Lorsqu’un identificateur n’est pas entre guillemets, il est stocké et résolu en majuscules.

  • Lorsqu’un identificateur est entre guillemets doubles, il est stocké et résolu exactement tel qu’il a été saisi, casse incluse.

Par exemple, les quatre noms suivants sont équivalents et tous se résolvent dans TABLENAME :

TABLENAME
tablename
tableName
TableName
Copy

En revanche, les quatre noms suivants sont considérés comme des valeurs uniques et différentes :

"TABLENAME"
"tablename"
"tableName"
"TableName"
Copy

Si ces identificateurs étaient utilisés pour créer des objets du même type (p. ex. des tables), ils donneraient lieu à la création de quatre objets distincts.

Migration à partir de bases de données qui traitent les identificateurs à double guillemets comme insensibles à la casse

Dans la norme ANSI/ISO pour SQL, les identificateurs entre guillemets doubles (identificateurs délimités) sont traités comme sensibles à la casse. Cependant, certaines entreprises fournissent des bases de données qui traitent les identificateurs entre guillemets doubles comme insensibles à la casse.

Si vous migrez vos données et vos applications de l’une de ces bases de données vers Snowflake, ces applications peuvent utiliser des guillemets doubles autour des identificateurs qui sont censés être insensibles à la casse. Cela peut empêcher Snowflake de résoudre correctement les identificateurs. Par exemple, une application peut utiliser des guillemets autour d’un identificateur en minuscules, alors que la base de données Snowflake possède l’identificateur en majuscules.

Pour contourner cette limitation, Snowflake fournit le paramètre de session QUOTED_IDENTIFIERS_IGNORE_CASE, qui permet à Snowflake de traiter les lettres minuscules des identificateurs à guillemets doubles comme des majuscules lors de la création et de la recherche d’objets.

Voir les sections suivantes pour plus de détails :

Note

La modification de la valeur de ce paramètre peut affecter votre capacité à trouver des objets existants. Voir Incidence de la modification du paramètre pour plus de détails.

Contrôle de la casse à l’aide du paramètre QUOTED_IDENTIFIERS_IGNORE_CASE

Pour configurer Snowflake afin qu’il traite les caractères alphabétiques des identificateurs entre guillemets doubles comme des majuscules pour la session, définissez le paramètre sur TRUE pour la session. Avec ce paramètre, tous les caractères alphabétiques des identificateurs sont stockés et résolus comme des caractères majuscules.

En d’autres termes, les huit noms suivants sont équivalents et se résolvent tous en TABLENAME :

TABLENAME
tablename
tableName
TableName
"TABLENAME"
"tablename"
"tableName"
"TableName"
Copy

Notez que ce paramètre n’a aucune incidence sur les limites des identificateurs sans guillemets en ce qui concerne les nombres, les caractères étendus et les espaces vides.

Incidence de la modification du paramètre

Le changement du paramètre de session QUOTED_IDENTIFIERS_IGNORE_CASE n’affecte que les nouveaux objets et requêtes :

  • Avec la valeur par défaut de FALSE, si un objet est créé à l’aide d’un identificateur entre guillemets avec un mélange de casse, Snowflake stocke l’identificateur en casse mixte.

  • Si le paramètre est modifié ultérieurement en TRUE, Snowflake ne sera pas en mesure de résoudre cet identificateur en casse mixte entre guillemets doubles et ne pourra pas récupérer cet objet.

Astuce

En raison de l’impact que la modification du paramètre peut avoir sur la résolution des identificateurs, nous recommandons vivement de choisir la méthode de résolution des identificateurs dès le début de la mise en œuvre de Snowflake. Ensuite, demandez à votre administrateur de compte de définir le paramètre au niveau du compte pour appliquer cette méthode de résolution par défaut.

Bien que le paramètre puisse toujours être remplacé au niveau de la session, nous n’encourageons pas la modification du paramètre par défaut, sauf si vous en avez explicitement besoin.

Les exemples suivants illustrent le comportement après avoir passé le paramètre de FALSE à TRUE :

-- Set the default behavior
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = false;

-- Create a table with a double-quoted identifier
CREATE TABLE "One" (i int);  -- stored as "One"

-- Create a table with an unquoted identifier
CREATE TABLE TWO(j int);     -- stored as "TWO"

-- These queries work
SELECT * FROM "One";         -- searches for "One"
SELECT * FROM two;           -- searched for "TWO"
SELECT * FROM "TWO";         -- searches for "TWO"

-- These queries do not work
SELECT * FROM One;           -- searches for "ONE"
SELECT * FROM "Two";         -- searches for "Two"

-- Change to the all-uppercase behavior
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = true;

-- Create another table with a double-quoted identifier
CREATE TABLE "Three"(k int); -- stored as "THREE"

-- These queries work
SELECT * FROM "Two";         -- searches for "TWO"
SELECT * FROM two;           -- searched for "TWO"
SELECT * FROM "TWO";         -- searches for "TWO"
SELECT * FROM "Three";       -- searches for "THREE"
SELECT * FROM three;         -- searches for "THREE"

-- This query does not work now - "One" is not retrievable
SELECT * FROM "One";         -- searches for "ONE"
Copy

De plus, si les identificateurs de deux tables ne diffèrent qu’au niveau de la casse, un identificateur peut se résoudre dans une table différente après avoir modifié le paramètre :

-- Set the default behavior
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = false;

-- Create a table with a double-quoted identifier
CREATE TABLE "Tab" (i int);  -- stored as "Tab"

-- Create a table with an unquoted identifier
CREATE TABLE TAB(j int);     -- stored as "TAB"

-- This query retrieves "Tab"
SELECT * FROM "Tab";         -- searches for "Tab"

-- Change to the all-uppercase behavior
ALTER SESSION SET QUOTED_IDENTIFIERS_IGNORE_CASE = true;

-- This query retrieves "TAB"
SELECT * FROM "Tab";         -- searches for "TAB"
Copy