Skip to content

fix(tinql): cap query length and nesting like tin - #19

Merged
eeeebbbbrrrr merged 2 commits into
fix-multi-field-scoresfrom
tinql-parse-limits
Oct 6, 2026
Merged

eeeebbbbrrrr merged 2 commits into
fix-multi-field-scoresfrom
tinql-parse-limits

Conversation

@claude

@claude claude Bot commented Oct 6, 2026 •

Copy link
Copy Markdown
Contributor

Before: Lead hands any TINQL text straight to pest. In a debug build, 700 nested parentheses (1.4 KB) or a 600-term OR chain (4.8 KB) overflows the stack and crashes the backend (SIGSEGV).

After: Every backend parse goes through postgres/src/tinql.rs, ported from tin's postgres/src/tinql.rs on develop. Text over 2048 bytes, or nested deeper than 64 (/[ levels, fails with SQLSTATE 54000 (program_limit_exceeded) before the parser runs. Messages and details match tin:

  • tinql query is too long / The query is N bytes; the limit is 2048 bytes.
  • tinql query is nested too deeply / The query nests N levels deep; the limit is 64.

It covers ==>, the score and highlight binds, tin.highlight(query => …), tin.score_inspect and tin.ql_parse. The tinql crate gains tin's max_bracket_depth and its unit tests.

The operator's evaluation tests move to #[pg_test]. They now reach PostgreSQL's error path, which a standalone test binary cannot load.

A debug build can still overflow on a 2 KB run of one-letter terms (a a a …). Release builds hold.

Tests: a session test mirrors tin's tinql_query_length_limit regress test across every entry point, including a generic-plan parameter. It fails before the fix.

Stacked on #18.

@claude
claude Bot requested review from eeeebbbbrrrr and piki October 6, 2026 18:19
@eeeebbbbrrrr
eeeebbbbrrrr added this pull request to stack #20 October 6, 2026 18:25
@claude
claude Bot force-pushed the tinql-parse-limits branch from 808b29a to c0877b5 Compare October 6, 2026 18:33
Claude and others added 2 commits October 6, 2026 19:02
Every TINQL parse in the backend now goes through postgres/src/tinql.rs,
ported from tin: text over 2048 bytes or nested deeper than 64 `(`/`[`
levels fails with SQLSTATE 54000 (program_limit_exceeded) before pest
runs. The parser recurses per bracket and the lowering per term, so
unbounded text could overflow the backend's stack and crash it. The
`==>` operator, score and highlight binds, tin.highlight's query
argument, tin.score_inspect, and tin.ql_parse all use the guarded parse.

tinql gains tin's max_bracket_depth and its unit tests.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012mKGtrg7DEhVPgqYrJtHGg
evaluate_text now reaches the guarded parse, which raises through
PostgreSQL's error machinery. That code references backend data symbols,
which the standalone test binary cannot resolve when it loads, so these
tests move to #[pg_test] like tin's tests of its guarded parse.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012mKGtrg7DEhVPgqYrJtHGg
@eeeebbbbrrrr
eeeebbbbrrrr marked this pull request as ready for review October 6, 2026 20:17
@eeeebbbbrrrr
eeeebbbbrrrr merged commit a22cd04 into main Oct 6, 2026
4 checks passed
@eeeebbbbrrrr
eeeebbbbrrrr deleted the tinql-parse-limits branch October 6, 2026 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant