Column-name case (lowercase / snake_case)

Delta Forge column names are lowercase / snake_case and case-preserving. The ODBC driver returns them verbatim; do not rely on uppercasing or lowercasing.

Syntax

SELECT customer_id, order_date FROM analytics.marts.fact_orders

Description

## The convention All Delta Forge column names are lowercase with snake_case word separation. `customer_id`, `order_date`, `total_amount`. Identifiers are case-preserving: a column created as `OrderDate` is stored as `OrderDate` and is distinct from `orderdate`. The ODBC driver returns column names exactly as they exist in the catalog. Application code that uppercases or lowercases names (e.g. for a case-insensitive lookup map) breaks against case-preserving identifiers. Use the names as the driver returns them. ## Generating SQL When your tool generates SQL (CASTs, JOINs, dbt macros), follow the same convention: - Lowercase / snake_case for new columns. - Quote with double quotes only when you must address a non-conforming legacy identifier. - Do not auto-uppercase identifiers; this changes the identity of the object on the server. This matters for tools like MicroStrategy and Power BI that historically uppercase identifiers in generated SQL. Configure them to preserve case if the option exists, or override the generated identifier explicitly. ## Aliases in result sets Aliases (`SELECT col AS My_Column`) are also case-preserving. The driver returns `My_Column` to the client; downstream code that compares against `my_column` will not match.

Examples

# Names are returned exactly as stored
for col in cur.description:
    print(col[0])  # 'customer_id', 'order_date', ...

# Quoting preserves case if you need to address an uppercase identifier
SELECT "CustomerID" FROM legacy.imported_table

Pitfalls

• Application code that maps columns into a case-insensitive dictionary (e.g. `dict([(c[0].lower(), v) for c, v in zip(desc, row)])`) silently masks duplicate column names that differ only in case. This is a footgun for legacy schemas that mix `Customer_ID` and `customer_id`; the lookup loses one of them.
• Tools that uppercase generated identifiers in DDL (`CREATE TABLE T(C INTEGER)`) end up with `T` and `C` as the stored names. Subsequent unquoted access still finds them (most SQL parsers fold unquoted names), but exact-match metadata queries will surprise you.

See Also

• ODBC_DATATYPE_MAPPING