You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
core: report the placeholders the analyzer used to walk past
Under SQLCEXPERIMENT=coreanalyzer several statement shapes lost their
parameters, so the generated function took fewer arguments than the query
has placeholders:
- INSERT ... SELECT: the engines report the source query with an empty
VALUES list rather than none, so the analyzer took the VALUES branch and
walked nothing. The query is analyzed now, and a placeholder selected
directly stands in for the column it lands in.
- UPDATE ... LIMIT and DELETE ... LIMIT, and LIMIT/OFFSET on a UNION,
INTERSECT or EXCEPT, were never looked at.
- ON DUPLICATE KEY UPDATE assignments were never looked at; they bind the
way SET does.
- x IN (SELECT ...) on MySQL arrives wrapped in a sublink, which the IN
node did not look through.
- x COLLATE c: SQLite puts the expression in the node's other field and
the collation's name where PostgreSQL puts the expression, so the
placeholder underneath was neither found nor typed.
- CALL: the compiler only sent SELECT, INSERT, UPDATE and DELETE through
the core, and the schema package skipped CREATE PROCEDURE. A procedure is
recorded now, with a void pseudo type as its result, and a CALL types
each placeholder from the procedure's declared parameter, by position or
by name, and names it after the parameter. The AST gains IsProcedure,
which both parsers set, since a function with only OUT parameters also
declares no return type.
A placeholder on the left of an IN list takes its type from the members,
the way the other operand of a comparison would.
In the core replay context 12 more cases pass, with no case regressing.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XZcKb4GFiZQbeo9oVmyF3m
0 commit comments