What causes "SQL query too long (max %d characters)" in Tencent/WeKnora?

Raise the validator's maxLength configuration to a value that fits your largest legitimate query.

SQL query too long (max %d characters)

Error message

SQL query too long (max %d characters)

What it means

sqlValidator.validateInput rejects any SQL string whose byte length exceeds the validator's configured maxLength. The library enforces a length ceiling as a basic input-safety guard before deeper parsing/validation, so oversized queries fail fast instead of being processed. It is a configuration-vs-input mismatch: the query is fine, but it is longer than the validator was set up to accept.

Source

Thrown at internal/utils/inject.go:1336

	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

// validateInput performs basic input validation
func (v *sqlValidator) validateInput(sql string) error {
	// Check for null bytes
	if strings.Contains(sql, "\x00") {
		return fmt.Errorf("invalid character in SQL query")
	}

	// Check length limits
	if len(sql) < v.minLength {
		return fmt.Errorf("SQL query too short (min %d characters)", v.minLength)
	}
	if len(sql) > v.maxLength {
		return fmt.Errorf("SQL query too long (max %d characters)", v.maxLength)
	}

	return nil
}

// validateSelectStmt validates a SELECT statement with configured options
func (v *sqlValidator) validateSelectStmt(stmt *pg_query.SelectStmt, result *SQLValidationResult) error {
	tablesInQuery := make(map[string]string) // table name -> alias

	// Check for UNION/INTERSECT/EXCEPT (compound queries)
	if stmt.Op != pg_query.SetOperation_SETOP_NONE {
		return fmt.Errorf("compound queries (UNION/INTERSECT/EXCEPT) are not allowed")
	}

	// Check for WITH clause (CTEs)
	if v.checkCTEs && stmt.WithClause != nil {
		return fmt.Errorf("WITH clause (CTEs) is not allowed")
	}

View on GitHub (pinned to 988cbb0330)

Solutions

Raise the validator's maxLength configuration to a value that fits your largest legitimate query.
Shorten the query: reduce the IN-list size, use a temp table/join instead of huge literals, or select fewer columns.
If the length check is not needed for your use case, disable/relax the length constraint in the validator options, if exposed.
Pre-truncate or split the workload into multiple smaller queries before calling the validator.

Example fix

// before: validator with default/small limit
v, _ := utils.NewSQLValidator(utils.ValidatorOptions{MaxLength: 1000})
v.Validate(hugeQuery) // "SQL query too long (max 1000 characters)"

// after
v, _ := utils.NewSQLValidator(utils.ValidatorOptions{MaxLength: 50000})

Defensive patterns

Strategy: validation

Validate before calling

const maxLen = 50000 // must match validator maxLength
if len(sql) > maxLen {
    return fmt.Errorf("query is %d bytes, exceeds max %d; shorten or raise maxLength", len(sql), maxLen)
}

Prevention

Keep maxLength config in sync with the largest query your application actually generates.
Log len(query) when building queries so oversized ones are visible before validation.
Avoid huge IN (...) lists and large embedded literals; use joins or parameters.
Add a unit test asserting your worst-case query passes validateInput.

When it happens

Trigger: Calling the library's SQL validation/injection-check API with a query string whose len(sql) > v.maxLength (the configured maximum, reported in the error message). Happens on any API path that runs validateInput before statement parsing.

Common situations: Long ORM-generated queries with large IN (...) lists; many JOINs or wide column lists; queries with embedded long literals or bulk VALUES rows; maxLength left at a small default while the app legitimately builds big queries.

Related errors

AI-assisted analysis of Tencent/WeKnora@988cbb0330 (2026-09-02). Data as JSON: /api/errors/77f6cec5afbd53e9. Report an issue: GitHub.