Yang Jie created SPARK-60457:
--------------------------------
Summary: CREATE TABLE CHECK constraints keep parameter markers in
predicateSql under legacy parameter substitution
Key: SPARK-60457
URL: https://issues.apache.org/jira/browse/SPARK-60457
Project: Spark
Issue Type: Bug
Components: SQL
Affects Versions: 5.0.0
Reporter: Yang Jie
With spark.sql.legacy.parameterSubstitution.constantsOnly=true, the parser
leaves parameter markers in the SQL text and BindParameters binds them during
analysis. A CHECK constraint stores its condition text as predicateSql, so the
marker stays there, and a write that checks the constraint through
predicateSql, which it does when no predicate was stored, cannot bind it. On a
V2 catalog:
{noformat}
spark.sql(
"CREATE TABLE t (id INT, ts TIMESTAMP, CONSTRAINT c CHECK (ts >=
current_timestamp() - make_interval(0, 0, 0, :d)))",
Map("d" -> 1))
// every later INSERT fails with UNBOUND_SQL_PARAMETER
{noformat}
The same happens for any CREATE TABLE condition whose predicate cannot be
translated to V2. ALTER TABLE keeps the predicate built from the optimized
condition for a condition with a marker (SPARK-60032), so it fails only when
that predicate cannot be translated either, but its predicateSql still shows
the marker: CHECK (id > :m) is stored as the predicate id > 0 with predicateSql
id > :m.
DEFAULT and GENERATED expressions reject parameter markers in the parser
(AstBuilder.getDefaultExpression and visitGeneratedColumn), while
visitCheckConstraint does not. Options are to reject them the same way, which
also rejects CHECK (id > :m) that works in this mode today, or to store the
condition text with the markers bound.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
