[Bug]: SQL PREPARE maps inner SQL syntax errors to 1105/HY000 instead of 1064/42000 #30434

Summary

SQL PREPARE name FROM '...' reports an inner SQL syntax error as generic MySQL error 1105 / HY000, instead of 1064 / 42000. The SQL is correctly rejected and the connection remains usable, but clients cannot reliably classify the failure using the normal syntax-error code/SQLSTATE.

Found while independently validating PR #30151. This is separate from the empty-CTE panic fixed there; an unrelated malformed SQL control reproduces the mapping problem without an empty CTE.

Verified revision / environment

• Commit: f149b512a6d24b0f1af22aa86f781833221c6608 (PR fix(parser): reject empty CTE bodies to avoid Format panic #30151, main-based).
• Linux amd64, Go 1.27.1; native prerequisites built from this revision.
• Real single-CN embedded MatrixOne cluster, MySQL TCP frontend, go-sql-driver/mysql client; one pinned physical sql.Conn throughout.
• No claim that latest main or 4.2-dev was independently executed for this issue.

Minimal reproduction

Execute through the MySQL client on the same connection:

PREPARE unrelated_syntax FROM 'SELECT FROM';
SELECT 1;

Actual error (independently observed):

Error 1105 (HY000): You have an error in your SQL syntax; check the manual that corresponds to your MatrixOne server version for the right syntax to use. syntax error at line 1 column 11 near " from";

SELECT 1 then succeeds. The failure is error classification, not a disconnect or panic.

Additional observed comparison on this revision:

Expected behavior

An inner SQL parser error in SQL PREPARE should retain syntax-error classification: 1064 / 42000, consistent with the other parser-facing entry points. Preserve the useful parser diagnostic and position. Do not rewrite unrelated planning, authorization, cancellation or runtime errors as syntax errors.

Root-cause analysis / existing ownership

The inner parse in pkg/sql/plan/build_dcl.go (buildPrepare, *tree.PrepareString case) calls mysql.ParseWithSQLMode and returns its parser error directly. pkg/sql/parsers/dialect/mysql/mysql_lexer.go (Lexer.Error) constructs a PositionedErr. In pkg/frontend/util.go, RewriteError recognizes *moerr.Error, while its default branch maps an untyped/non-moerr error to the generic MySQL error. The inner PREPARE parse error therefore loses SQL syntax-error classification at the frontend boundary.

Check other existing inner-parse entry points, including parsePreparedStatement, before choosing the narrowest shared correction. Prefer the existing parser-error conversion owner; avoid matching error-message strings, duplicating conversion rules, or adding work to successful SQL execution.

These files/paths are unchanged between PR #30151 and its merge base a53390c57de48ac280249ff0e88831e502e20fb0. This is an existing error-mapping gap, not a new mapping branch introduced by #30151. Historical introduction commit is not established.

Acceptance / focused validation

• Public SQL PREPARE of ordinary malformed SQL returns 1064 / 42000.
• Cover empty-CTE inner SQL where the parser fix is present; no internal-panic response.
• Same physical connection executes SELECT 1 immediately after rejection.
• Valid SQL PREPARE / EXECUTE / DEALLOCATE still works.
• Direct SQL and binary COM_STMT_PREPARE syntax-error behavior remains correct.
• Confirm unrelated error classes retain their codes; no broad error conversion or success-path parsing/allocation overhead.
• Add a small regression through the real frontend entry point; parser-only assertions do not prove the client-visible mapping.

Evidence

Independent review and executed public-path results: #30151 (review)

The review includes the complete temporary test source, exact revision, commands and terminal results. Parser packages passed; public SQL probe passed after explicitly distinguishing the observed entrypoint-specific error codes. The original 1064 assertion on SQL PREPARE failed and prompted this investigation.