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 ($).

  • Are stored and resolved as uppercase characters (e.g. id is stored and resolved as 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 :

  • The case of the identifier is preserved when storing and resolving the identifier (e.g. "id" is stored and resolved as id).

  • The identifier can contain and can even start with any ASCII character from the blank character (32) to the tilde (126).

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

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

    crée une table nommée :

    quote"andunquote"
    

    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

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"
"идентификатор"

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"

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

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

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

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.

Migrating From Databases That Treat Double-Quoted Identifiers as Case-insensitive

In the ANSI/ISO standard for SQL, identifiers in double quotes (delimited identifiers) are treated as case-sensitive. However, some companies provide databases that treat double-quoted identifiers as case-insensitive.

If you are migrating your data and applications from one of these databases to Snowflake, those applications might use double quotes around identifiers that are intended to be case-insensitive. This can prevent Snowflake from resolving the identifiers correctly. For example, an application might use double quotes around an identifier in lowercase, and the Snowflake database has the identifier in uppercase.

To work around this limitation, Snowflake provides the QUOTED_IDENTIFIERS_IGNORE_CASE session parameter, which causes Snowflake to treat lowercase letters in double-quoted identifiers as uppercase when creating and finding objects.

See the next sections for details:

Note

Changing the value of the parameter can affect your ability to find existing objects. See Incidence de la modification du paramètre for details.

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

To configure Snowflake to treat alphabetic characters in double-quoted identifiers as uppercase for the session, set the parameter to TRUE for the session. With this setting, all alphabetical characters in identifiers are stored and resolved as uppercase characters.

In other words, the following eight names are equivalent and all resolve to TABLENAME:

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

Note that the parameter has no effect on any of the limitations for unquoted identifiers with regards to numbers, extended characters, and blank spaces.

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.

  • If the parameter is later changed to TRUE, Snowflake will not be able to resolve that double-quoted mixed case identifier and will not be able retrieve that object.

Astuce

Due to the impact that changing the parameter can have on resolving identifiers, we highly recommend choosing the identifier resolution method early in your implementation of Snowflake. Then, have your account administrator set the parameter at the account level to enforce this resolution method by default.

Although you can override this parameter at the session level, we don’t encourage changing the parameter from the default, unless you have an explicit need to do so.

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"

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"