The error signals that a CALL statement or cursor tried to fetch more dynamic result sets than the routine declared.
no_additional_dynamic_result_sets_returned appears when a PostgreSQL stored procedure finishes execution without returning the extra result sets the caller expected. Align the caller’s fetch logic with the procedure’s OUT parameters or RETURN NEXT statements to resolve the mismatch.
no_additional_dynamic_result_sets_returned
The condition name no_additional_dynamic_result_sets_returned maps to SQLSTATE 2001 in PostgreSQL. It fires when a caller tries to fetch an extra dynamic result set that the invoked stored procedure did not supply.
The server signals this edge-case to prevent undefined behavior, cursor corruption, or runaway network reads.
Fixing it ensures stable cursor iteration and predictable client logic.
The error usually arises when a client library or application expects more result sets than the procedure’s RETURNS TABLE, OUT parameters, or RETURN NEXT statements actually deliver.
Mismatched FETCH statements, incorrectly set refcursor counts, and driver methods that assume multiple result batches also trigger the condition.
First, confirm the exact number of dynamic result sets the procedure is designed to emit.
Inspect the routine definition with \df+ or pgAdmin.
Next, adjust application code so it stops calling FETCH or nextset() after the last legitimate set. When refcursors are used, close the cursor once done.
When using psql, calling FETCH ALL on a refcursor after the final SET returns this error. Stop fetching once FOUND is false.
In psycopg3, calling cursor.nextset() after it already returned None raises the server condition.
Wrap the call in a conditional that checks for None.
Document every procedure with the exact count of expected result sets. Use RETURNS SETOF RECORD only when multiple sets are guaranteed.
Implement defensive coding on the client side: break out of fetch loops when no more sets are reported instead of assuming a fixed count.
too_many_result_sets_returned indicates the opposite mistake - the routine returned more sets than declared.
Adjust the RETURNS clause.
invalid_cursor_state appears when you FETCH from a cursor that is already closed. Ensure proper cursor lifecycle management.
.
No. It only appears when stored procedures or functions can return multiple dynamic result sets.
Suppressing it hides a logic flaw and risks data loss. Always align fetch loops with real output.
Versions 10+ follow SQL/MED condition naming, including 2001 for this error.
Galaxy’s SQL editor highlights routine definitions and warns when your FETCH loop exceeds declared result sets, preventing the error early.
.avif)
.avif){kind=logo}
