Claude Opus 5
ba5c796b36
CI (SIAX Cloud) / security (push) Successful in 30s
CI (SIAX Cloud) / integration (push) Successful in 56s
CI (SIAX Cloud) / quality (push) Successful in 1m23s
CI (SIAX Cloud) / integration (pull_request) Successful in 49s
CI (SIAX Cloud) / security (pull_request) Successful in 24s
CI (SIAX Cloud) / quality (pull_request) Successful in 1m18s
Security Scan (SIAX Cloud) / security (push) Successful in 23s
Security Scan (SIAX Cloud) / security (pull_request) Successful in 23s
Neither changes behaviour; both replace an assertion with a measurement.
BI-P014's escaping strategy rests on DuckDB treating a backslash as a literal
character, so that doubling `'` is sufficient. Verified on 1.5.5 rather than
assumed: `SELECT length('a\\b')` returns 4, and `SELECT 'a\''` is a parser
error ("unterminated quoted string") — which is exactly what a NON-escaping
backslash produces. In a dialect where `\'` closed the literal, doubling would
not be enough, so the claim is worth pinning to a run.
BI-P017's FROM/JOIN scan is conservative where it is unsure, and that has a
cost worth naming rather than discovering: ClickHouse's `ARRAY JOIN arr` takes
a COLUMN, not a table, and this guard refuses it. A false refusal an analyst
can see and report is the right side of that trade; a false ADMISSION is not.
Supporting it means teaching the scan which JOIN flavours take a non-table
target, which is the direction that grows holes — so it stays refused until
someone needs it and can add it WITH a corpus entry proving the narrowing did
not open anything else.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>