CAST/TRY_CAST/CONVERT reject bare literal operands — CAST('125' AS BIGINT) does not parse

[fupelaqu]

CAST('125' AS BIGINT) is a parse error, and so is every other conversion of a bare literal: no conversion production accepts a literal operand — CAST / TRY_CAST / SAFE_CAST / CONVERT operands are all identifier-shaped (sql/src/main/scala/app/softnetwork/elastic/sql/parser/function/convert/package.scala:28-60), and zero tests exercise a literal operand.

Repro

CAST('125' AS BIGINT)      -- parse error (any statement position)
SELECT CAST('125' AS BIGINT) FROM t   -- parse error
TRY_CAST(1 AS DOUBLE)      -- parse error

Workaround (works today)

The postfix cast operator accepts a literal: '125'::BIGINT (identifierWithValue >> cast, parser/type/package.scala:106). Note :: is always unsafe (CastOperator.safe = false), so there is currently no safe-cast spelling over a bare literal at all — the safe path needs TRY_CAST over a function-of-constants.

Context

• Found specifying/implementing the FROM-less SELECT handshake (Support FROM-less SELECT of literal expressions — SELECT 1 is the connection/health idiom of Tableau and Superset and is rejected #251): the constant-cast accept row had to use the :: spelling, and the documentation now points users there.
• Same operand-surface family as Identifier quoting coverage: backticks rejected in every position; double-quoted table names unparseable in FROM #252 (identifier quoting): BI tools and ORMs emit CAST(<literal> AS <type>) freely — MySQL, PostgreSQL, SQL-92 all accept it.
• Pre-existing gap; nothing regressed. Enhancement: extend the conversion operand productions to accept literals (and thereby give literals a safe-cast spelling via TRY_CAST).