2201W

At a glance

A LIMIT or FETCH row count fails a form-specific guard. Fixed paths report LIMIT must not be negative; the parser separately rejects a literal NULL row count in FETCH FIRST ... WITH TIES.

Representative messages

The representative guards use these primary texts:

Meaning

The executor evaluates an ordinary LIMIT count: NULL is interpreted as no count (LIMIT ALL), zero is valid and returns no rows, and a negative value emits 2201W. The parser has a separate guard for an unadorned NULL constant in FETCH FIRST ... WITH TIES; it is not a blanket rule that every nullable LIMIT expression has the same behavior. OFFSET is handled by 2201X.

Diagnosis

Identify whether the message came from an ordinary LIMIT evaluation or the WITH TIES parser rule, then inspect the evaluated expression and its type. Keep NULL-without-ties, literal NULL-with-ties, zero, and negative values separate. A hidden expression can pass the parser’s narrow A_Const check, so classify the resulting behavior from the actual statement and message.

Response

For ordinary LIMIT, use a non-negative count or NULL when an unlimited result is intended. For WITH TIES, provide a non-NULL row count accepted by that syntax. If the negative-count or parser ERROR occurred inside an explicit transaction, roll back or roll back to the existing savepoint before retrying; autocommit can retry the corrected statement.

Versions

The locked catalogue records this condition from 8.4.0; the fixed source paths here are PostgreSQL 18.6. No natural runtime observation is claimed for this page.

Related

2201X, 22012

Sources

The executor NULL/zero/negative handling is in src/backend/executor/nodeLimit.c#L347-405, and the literal WITH TIES NULL guard is in src/backend/parser/parse_clause.c#L1890-1907. The structured evidence record retains both primary roles; no natural runtime was run.