SnowDDL
  • 👋Introduction
  • 🚩Getting started
  • 📋Main features
  • 🪤SnowDDL vs. Declarative DCM
  • In-depth guides
    • 👓Object identifiers
    • 📐Data types
    • 📦Object types
    • 🎭Role hierarchy
    • 🚧Permission model
    • 🔦Other guides
      • Administration user
      • Integrations
      • Inbound shares
      • Object OWNERSHIP
      • Safe & unsafe DDL
      • Dependency management
      • Short hash explained
      • Env Prefix explained
      • Team workflow
      • Limitations & workarounds
      • Fivetran
      • Airbyte
      • Encrypt user passwords
      • Iceberg Tables
  • Basic usage (CLI + YAML)
    • 💻CLI interface
    • 📦YAML configs
      • ACCOUNT PARAMETER
      • ACCOUNT POLICY
      • AGGREGATION POLICY
      • ALERT
      • AUTHENTICATION POLICY
      • BUSINESS ROLE
      • DATABASE
      • DYNAMIC TABLE
      • EVENT TABLE
      • EXTERNAL ACCESS INTEGRATION
      • EXTERNAL FUNCTION
      • EXTERNAL TABLE
      • FILE FORMAT
      • FUNCTION
      • HYBRID TABLE
      • ICEBERG TABLE
      • MASKING POLICY
      • MATERIALIZED VIEW
      • NETWORK POLICY
      • NETWORK RULE
      • PERMISSION MODEL
      • PIPE
      • PLACEHOLDER
      • PROCEDURE
      • PROJECTION POLICY
      • RESOURCE MONITOR
      • ROW ACCESS POLICY
      • SCHEMA
      • SECRET
      • SEQUENCE
      • SHARE (outbound)
      • STAGE
      • STAGE FILE
      • STREAM
      • TABLE
      • TASK
      • TECHNICAL ROLE
      • USER
      • VIEW
      • WAREHOUSE
    • 🏷️YAML placeholders
    • 📬YAML tag !include
    • 🔐YAML tag !decrypt
  • Single DB
    • 🦀Overview
  • Advanced usage (Python)
    • ⚙️Programmatic config
    • 🐍Architecture overview
      • 🔵Blueprints
      • 🟣Config
      • 🟠Parsers
      • 🟢Resolvers
      • 🔴Engine
    • 🏗️Query builder & formatter
  • Breaking changes log
    • 0.45.0 - March 2025
    • 0.41.0 - January 2025
    • 0.37.0 - December 2024
    • 0.36.0 - November 2024
    • 0.33.0 - October 2024
    • 0.27.0 - May 2024
  • Links
    • GitHub repository
    • PyPI package
    • YouTube tutorials
    • Changelog
    • LinkedIn profile
Powered by GitBook
On this page
  • Identifier rules
  • Rationale
  • Examples
  1. In-depth guides

Object identifiers

PreviousSnowDDL vs. Declarative DCMNextData types

Last updated 8 months ago

Identifier rules

SnowDDL takes a slightly different approach to resolution of .

  • 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 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.

  • Some words in Snowflake are (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".

  • Snowflake has a session parameter which is called . It applies upper case transformation to all identifiers, including identifiers enclosed in ". SnowDDL will work the same way regardless of value of this parameter.

  • 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

in examples is ALICE.

  • Warehouse name in config: analytics_wh

    • Identifier in SQL query: "ANALYTICS_WH"

    • Identifier with env prefix: "ALICE__ANALYTICS_WH"

  • 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"

👓
Snowflake identifiers
env prefix
reserved
QUOTED_IDENTIFIERS_IGNORE_CASE
Env prefix