* feat(database) :: stop casting variables to TEXT on PostgreSQL, MySQL and SQL Server
SQLPage binds every variable as a string. The generated CAST(? AS TEXT)
forced the database to type the parameter as text, which is only needed
where parameter type inference is unpredictable (SQLite, ODBC). On the
natively supported databases the cast was redundant, and on SQL Server it
was harmful: the parameter is bound as NVARCHAR(MAX), and casting it to a
narrow VARCHAR mangled non-ASCII values before comparing them to nvarchar
columns. Generated SQL is now cleaner, e.g. WHERE id = $1 instead of
WHERE id = CAST($1 AS TEXT).
SQLite and ODBC-backed databases (Oracle, DuckDB, Snowflake, Generic)
keep the cast to preserve their comparison semantics.
Verified with the full test suite against SQLite, PostgreSQL, MySQL and
SQL Server, including new fixtures for integer-column comparisons,
numeric-literal comparisons, and unicode nvarchar comparisons on SQL
Server.
* fix(odbc) :: keep the text cast around variables on ODBC connections
The ODBC job in CI failed because the cast was removed based on the
database name behind the driver: PostgreSQL reached through psqlodbc no
longer received CAST(? AS TEXT), and the driver could not determine the
type of context-free parameters such as in 'WHERE ? <> ? OR ? IS NULL',
failing with 'could not determine data type of parameter'.
The cast decision now keys off the connection kind: native PostgreSQL,
MySQL and SQL Server connections keep no cast, while every ODBC
connection keeps the previous per-database cast, since ODBC drivers
provide no parameter type information.
Adds a fixture comparing variables without any surrounding type context,
which exercises exactly this scenario on every database.
* refine: drop the text cast on MySQL, SQL Server and DuckDB behind ODBC too
ODBC connections were conservatively keeping the cast for every database.
Testing against real ODBC drivers shows the cast is needed only where the
parameter type cannot be determined without it:
- psqlodbc -> PostgreSQL: needed. Without it, context-free parameters fail
with 'could not determine data type of parameter' (the earlier CI failure).
- sqliteodbc -> SQLite: needed. Without it, '? = 1' compares text against an
integer and silently returns false, like on native SQLite.
- duckdb-odbc: not needed. The full test suite passes without the cast, as
DuckDB defaults untyped parameters to VARCHAR.
The cast is therefore dropped for MySQL, SQL Server and DuckDB behind ODBC,
mirroring their native behavior (MySQL and SQL Server convert the bound
string at execution time, which also fixes the unicode mangling for SQL
Server reached through ODBC), and kept for PostgreSQL, SQLite, Oracle,
Snowflake and unknown databases.
Verified with the full test suite on native SQLite, PostgreSQL, MySQL and
SQL Server, and through ODBC on PostgreSQL, SQLite and DuckDB. The only
ODBC failure is a pre-existing database-filesystem timestamp test that also
fails on main.
* docs(changelog): make variable cast entry concise and user-oriented
The previous entry described internal CAST(? AS TEXT) generation
and load-bearing type affinity details. Rephrase for users:
focus on the visible fix (MSSQL nvarchar Unicode mangling)
and the general simplification (no unnecessary text cast
where the database infers the type).
* docs(changelog): add issue references for variable cast fix
Fixes: #516 (CONTAINS with MSSQL variable fails due to CAST), #1154
(LIMIT/OFFSET with variables fails on MySQL/MariaDB).
See: #1317 (per-database logic still scattered, this is a step
toward the SqlDialect abstraction).
* test: simplify variable cast tests and add focused repros for #516 and #1154
- Replace verbose pattern-matching in sql.rs with helpers sql_for/
odbc_sql_for and table-driven asserts; keep coverage but drop
ceremony and duplicated error messages.
- Keep limit and mssql tests as one-liners checking the generated
SQL string.
- Trim .sql fixtures to minimal scaffold and add GH issue links as
comments. New fixtures:
* variable_limit_offset (MySQL, fixes#1154) — LIMIT/OFFSET with SET
variables must not be wrapped in CAST.
* variable_mssql_contains (MSSQL, fixes#516) — EXEC sp_executesql
with a variable must not be wrapped in CAST.
- Simplify existing variable fixtures and add issue links, keep them
short and readable.
* test: make variable fixtures self-contained
Remove 'same root cause' and inaccurate GH links that referenced
other files. Each fixture now describes its own invariant without
assuming reader context from another file.
* fix: mssql test escaping and improve changelog
- Fix variable_mssql_contains test: avoid nested single quotes in
sp_executesql string that caused 'Incorrect syntax near It' on
CI. Use parameterised expected value instead of embedding
'It works !' inside the inner N'...' string.
- Improve CHANGELOG: one main bullet about removing CAST with
subpoints for PostgreSQL/MySQL/DuckDB, SQL Server nvarchar/
CONTAINS/EXEC, MySQL LIMIT/OFFSET, and retained cast on SQLite/
ODBC. Move fixes:/see: to PR description.
* Refactor SQL variable cast tests to use typed assertions
* clippy
* Move database-specific SQL tests into per-database subdirectories
Restructure tests so files that only work on a single database engine
are
organized under `database-specific/<engine>/` instead of using long
`_no...`
suffixes. Add a dedicated test that runs these files only when the
current
database matches, and simplify the generic test runner by extracting
shared
execution logic.
* rename mssql variable fixture to match its sp_executesql repro
The file reproduces issue #516 (CONTAINS rejects CAST expressions), but
the query itself uses sp_executesql, which has the same restriction
without needing a full-text index. Rename the fixture to reflect that
and add a comment explaining why CONTAINS is not used directly.
Update Biome to 2.5.4 and Playwright to 1.61.1, align type definitions with Node 24, and exclude SVG assets that the new Biome release starts parsing from the existing lint scope.
Depend directly on sqlx-core-oldapi and use its module-level runtime APIs. SQLPage uses no SQLx query or derive macros, so this removes sqlx-oldapi and sqlx-macros-oldapi from the resolved graph.
macOS arm64 cargo build --release: 43,037,040 -> 43,020,288 bytes (-16,752 bytes, -0.04%).
Cover cases where SQLPage functions span database and per-row
boundaries, including predicates, projections, and shared request/row
values.
Also add documentation to `QueryResult` and `BoundQuery`, tidy up
borrow expressions in the OIDC client, and rename a conflicting `rows`
alias in a test fixture.
Replace the `StmtParam`/`ParameterExtractor` machinery with a shared
`SqlPageExpr` type parameterized over its input source, distinguishing
standalone expressions from per-row expressions via the type system.
Rename `ParsedSqlFile` to `SqlFile` and split SQL parsing into dedicated
`dialect`, `rewrite`, and `statement` submodules. Queries are now
rewritten into either a database query with bindings and computed
columns, or a single-row query evaluated without a database round trip.
Make `SqlPageFunctionName` parsing case-insensitive and support
SQLPage-computed projections and nested functions over query results.
SQLPage functions that are the whole value of a selected column now
execute after the database query, once per returned row. If the query
returns no rows, the function is not called. This ensures deterministic
behavior and prevents expensive or side-effectful operations from
running unnecessarily.
* fix(oidc): bind logout URLs to the current session (forced-logout CSRF)
Logout URLs were signed only over the redirect target and a timestamp, so any
valid, unexpired logout URL would clear whoever's cookies followed it. The
logout signature now also covers the caller's sqlpage_auth cookie, so a logout
URL only logs out the session it was issued for. Generation and verification
select the same cookie (the last of any duplicates, matching how RequestInfo
merges them) so the check stays consistent.
* style: run cargo fmt on the logout cookie test
In production, error responses must not leak the SQL statement, the source
file path, the raw database error, environment values, or configuration, for
ANY output format. In development the full detail is shown, and the full error
is always logged server-side.
This centralizes the dev-vs-production decision in a single place. An internal
error stays a full `anyhow::Error` everywhere; the only place that turns it into
a user-facing representation is `ClientError::new` in `src/webserver/error.rs`,
which is also the only caller of `DevOrProd::is_prod`. Every renderer (HTML,
JSON, NDJSON, SSE, CSV) and the header/pre-body path obtains a `ClientError`
from that one function and only formats it; none of them inspect the
environment. Leaking is therefore impossible by construction: a renderer cannot
emit what it never receives.
The error type, the production message, `get_backtrace_as_strings`, and the
error-component data construction live in `error.rs`; `render.rs` only renders
components and formats a `ClientError`.
The csv and download components built the Content-Disposition header by
string-interpolating the user-supplied filename. A filename containing
characters such as ';', '"' or '=' could inject an additional header
parameter (e.g. a second, agent-preferred filename*=...), letting an app
that interpolates untrusted data into the filename smuggle a different
download name past the intended one.
Build the header with actix-web's structured ContentDisposition type so
the filename is always a single, properly quoted/escaped value and cannot
create new parameters.
Prayag Bhakar