Skip to content

Type SQLExpression and spark expr() as LiteralString#540

Open
NickCrews wants to merge 1 commit into
duckdb:mainfrom
NickCrews:literalstring-sqlexpression
Open

Type SQLExpression and spark expr() as LiteralString#540
NickCrews wants to merge 1 commit into
duckdb:mainfrom
NickCrews:literalstring-sqlexpression

Conversation

@NickCrews

Copy link
Copy Markdown
Contributor

Motivation

SQLExpression() (and the pyspark-compat expr(), which wraps it) parse raw SQL, so passing a string built from untrusted input is an injection risk. PEP 675's LiteralString lets type checkers catch this statically: literal strings and compositions of literals pass, while dynamically constructed strings are flagged.

##Changes
_duckdb-stubs/init.pyi: SQLExpression(expression: str) → SQLExpression(expression: LiteralString)
duckdb/experimental/spark/sql/functions.py: expr(str: str) → expr(str: LiteralString) (annotation and docstring)
tests/fast/test_sql_expression.py: test showing a dynamically built string still works at runtime but requires a # type: ignore[arg-type] to pass typechecking
Notes
Runtime behavior is unchanged — this only affects static typing. Users who intentionally build SQL dynamically can suppress with # type: ignore[arg-type] (mypy) or cast.

🤖 Generated with Claude Code

Encourages static detection of SQL injection: passing a dynamically
built string to SQLExpression() or the spark expr() function now fails
typechecking unless explicitly suppressed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant