fix(databricks)!: string-promote COALESCE/IF/CASE per findWiderCommonType [CLAUDE]

[RichardHughes-amp]

Problem

For the databricks dialect, least-common-type functions — COALESCE (and IFNULL/NVL, which parse to Coalesce), IF, and CASE — annotate as the numeric type when an argument is text and the rest are numeric. Real Databricks resolves these to string (Spark's findWiderCommonType string promotion).

from sqlglot.optimizer.annotate_types import annotate_types
from sqlglot import parse_one

schema = {"tbl": {"int_col": "INT", "str_col": "STRING"}}
e = parse_one("SELECT COALESCE(tbl.int_col, tbl.str_col) FROM tbl", dialect="databricks")
annotate_types(e, schema=schema, dialect="databricks").selects[0].type
# before: BIGINT   after: STRING

spark/spark2/hive are already correct (they string-promote via their lattice); only databricks is affected.

Root cause

Databricks defines its own COERCES_TO lattice in the opposite direction from Hive/Spark — text coerces into numeric/temporal rather than numeric/temporal into text. LCT functions fold through that lattice via _annotate_by_args → _maybe_coerce, so the numeric type always wins regardless of argument order.

That lattice was introduced deliberately in #5096 on the premise that Databricks defaults to ANSI mode (where open-source Spark's AnsiTypeCoercion.findWiderTypeForString returns LONG for string + int, not string).

Why the ANSI premise doesn't hold for Databricks

Verified on a Databricks serverless warehouse (which is always ANSI):

SELECT
  typeof(coalesce(cast(1 as int), 'abc')),                  -- string
  typeof(coalesce(cast(1.5 as double), 'abc')),             -- string
  typeof(coalesce(cast('2020-01-01' as date), 'abc')),      -- string
  typeof(coalesce(interval 1 day, 'abc')),                  -- string
  typeof(if(true, cast(1 as int), 'abc')),                  -- string
  typeof(case when true then cast(1 as int) else 'abc' end);-- string

Databricks string-promotes these functions even under ANSI, contrary to open-source Spark's AnsiTypeCoercion. It follows the non-ANSI stringPromotion rule — (StringType, AtomicType) if t2 != BinaryType && t2 != BooleanType (plus interval). The excluded combinations error:

coalesce(cast(1 as boolean), 'abc')  -> [DATATYPE_MISMATCH.DATA_DIFF_TYPES]
coalesce(cast(1 as binary), 'abc')   -> [DATATYPE_MISMATCH.DATA_DIFF_TYPES]

Fix

Three Databricks-scoped annotators for Coalesce/If/Case: if a value argument is text and none is boolean/binary, the result is text; otherwise fall back to the existing numeric-widening behavior. boolean/binary + text and GREATEST/LEAST (which require a common type and error on mixed text/numeric in Databricks) are intentionally left on the fallback — there is no representable "type mismatch error" annotation, so their current best-effort type is retained.

Scoped to Databricks only; Spark/Hive and all other dialects are unchanged. Arithmetic coercion ('5' + 3 -> INT) is unaffected — it goes through BINARY_COERCIONS, not COERCES_TO.

Tests

tests/fixtures/optimizer/annotate_functions.sql: the Databricks COALESCE/IF rows for text + numeric/date/interval now assert STRING; boolean/binary rows keep their current annotation; added COALESCE/NVL/CASE cases and an all-numeric regression. Each asserted result matches the empirical typeof(...) output above.

[RichardHughes-amp]

We're just gonna ignore this one for a while until we've got some consensus as to why I'm seeing completely different behavior in Databricks from what seems to be expected.

[geooo109]

@RichardHughes-amp thanks for the PR once again, let me take a look.

[geooo109]

@RichardHughes-amp can you run in databricks the command SET -v and validate that ansi_mode is true ?

if it's not set it by SET ansi_mode = true

Databricks ANSI default mode = true

[geooo109]

I haven't worked on CASE in the original PR, as it seems databricks promotes the type here to BIGINT, lets check hive/spark and use promote=true if this is true.

[geooo109]

Let's remove this test entirely. (isn't valid for ANSI, probably missed it)

[RichardHughes-amp]

It turns out I had ANSI mode off! All of my confusion stemmed from me previously getting incorrect instructions on how to check if my Databricks warehouse was running in ANSI mode. The pre-existing behavior is correct, and I believe this PR is unnecessary.