[SPARK-57379][SQL] Block temporary variables in CHECK constraint expressions

[yadavay-amzn]

What changes were proposed in this pull request?

Block references to temporary (session) variables in CHECK constraint expressions, on both the CREATE/REPLACE TABLE path and the ALTER TABLE ... ADD CONSTRAINT path. A CHECK constraint that references a session variable is now rejected at analysis time with INVALID_TEMP_OBJ_REFERENCE.

The check mirrors the structural placement of the existing non-deterministic-constraint validation in both the CREATE/REPLACE TABLE (ResolveTableSpec) and ALTER TABLE ... ADD CONSTRAINT (CheckAnalysis) paths. It uses INVALID_TEMP_OBJ_REFERENCE — the canonical error class already raised when a persistent view references a temporary variable — rather than the generated-column-specific error used by SPARK-57360. Detection scans the constraint expression for any VariableReference node, so nested references (e.g. inside a CAST) are caught.

Why are the changes needed?

A CHECK constraint is persisted with the table, but a temporary/session variable is session-scoped and will not exist in other sessions, making the persisted constraint invalid. Today both paths silently accept it:

DECLARE OR REPLACE VARIABLE my_var INT DEFAULT 5;

-- Both currently succeed and persist CHECK (val > my_var):
CREATE TABLE t (id INT, val INT, CONSTRAINT c1 CHECK (val > my_var)) USING parquet;

CREATE TABLE t2 (id INT, val INT) USING parquet;
ALTER TABLE t2 ADD CONSTRAINT c2 CHECK (val > my_var);

Spark already blocks the analogous case for persistent views via INVALID_TEMP_OBJ_REFERENCE; this extends the same protection to CHECK constraints.

Does this PR introduce any user-facing change?

Yes. Creating or altering a table with a CHECK constraint that references a temporary variable now fails with INVALID_TEMP_OBJ_REFERENCE instead of silently persisting an invalid constraint. No previously-valid constraint is affected.

How was this patch tested?

New tests in CheckConstraintSuite covering CREATE TABLE, REPLACE TABLE, and ALTER TABLE ADD CONSTRAINT, including a nested reference (CHECK (i > CAST(my_var AS BIGINT))) to confirm detection is recursive, a qualified variable name (session.my_var), and a happy-path guard (a non-variable constraint still succeeds). CTAS/RTAS cannot carry CHECK constraints (the parser rejects them), so they need no coverage. Verified the tests fail without the fix.

Was this patch authored or co-authored using generative AI tooling?

Yes.