# Object identifiers

## Identifier rules

SnowDDL takes a slightly different approach to resolution of [Snowflake identifiers](https://docs.snowflake.com/en/sql-reference/identifiers-syntax.html).

* Identifiers are always upper case.
* Identifiers are always enclosed in `"` (double-quotes) when formatted for SQL queries.
* Only `ascii_letters`(a-z), `digits` (0-9), `_` (underscore) and `$` (dollar) characters are allowed.
* For complex identifiers (with [env prefix](/guides/other-guides/env-prefix.md) or role suffix), the delimiter is always `__` (double underscore).

## Rationale

* Lower case identifiers are usually created by accident. Unlike upper case identifiers, lower case identifiers must be enclosed in `"` to access. Mix of lower case and lower case identifiers cause a lot of confusion. SnowDDL does not allow lower case identifiers to prevent this confusion from happening.<br>
* Some words in Snowflake are [reserved](https://docs.snowflake.com/en/sql-reference/reserved-keywords.html) (e.g. `CREATE`, `TABLE`, `WHEN`). Such words cannot be used as identifiers without being enclosed in `"`. However, the list of reserved words is being updated all the time, and a word which is not reserved today may become reserved tomorrow. SnowDDL makes sure all identifiers will be valid in DDL queries regardless of current state of "reserved words".<br>
* Snowflake has a session parameter which is called [`QUOTED_IDENTIFIERS_IGNORE_CASE`](https://docs.snowflake.com/en/sql-reference/parameters.html#quoted-identifiers-ignore-case). It applies upper case transformation to all identifiers, including identifiers enclosed in `"`. SnowDDL will work the same way regardless of value of this parameter.<br>
* For complex identifiers a single `_` underscore is not good enough to identify multiple parts of identifier. Collisions are possible. For example, if you have schema `AAA.BBB_CCC` and schema `AAA_BBB.CCC`, generation of schema role name with `_` single underscore as glue will return exactly the same identifier for both. SnowDDL uses `__` (double underscore) in order to mitigate this and improve readability.

## Examples

[Env prefix](/guides/other-guides/env-prefix.md) in examples is `ALICE`.

* Warehouse name in config: `analytics_wh`
  * Identifier in SQL query: `"ANALYTICS_WH"`
  * Identifier with env prefix: `"ALICE__ANALYTICS_WH"`<br>

* Table name in config: `my_db.bookings.airports`

  * Identifier in SQL query: `"MY_DB"."BOOKINGS"."AIRPORTS"`
  * Identifier with env prefix: `"ALICE__MY_DB"."BOOKINGS"."AIRPORTS"`

* Function name in config: `my_db.bookings.lang(varchar)`

  * Identifier in SQL query: `"MY_DB"."BOOKINGS"."LANG"(VARCHAR)`
  * Identifier with env prefix: `"ALICE__MY_DB"."BOOKINGS"."LANG"(VARCHAR)`

* Business role name in config: `bookings_analyst`

  * Identifier in SQL query: `"BOOKINGS_ANALYST__B_ROLE"`
  * Identifier with env prefix: `"ALICE__BOOKINGS_ANALYST__B_ROLE"`

* Owner schema role for schema: `MY_DB.BOOKINGS`
  * Identifier in SQL query: `"MY_DB__BOOKINGS__OWNER__S_ROLE"`
  * Identifier with env prefix: `"ALICE__MY_DB__BOOKINGS__OWNER__S_ROLE"`


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.snowddl.com/guides/object-identifiers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.