How to fix 39001: invalid_sqlstate_returned in PostgreSQL

Inspect the PostgreSQL log or the client stack trace to identify the function or extension that triggered the error. The log entry for 39001 usually includes the shared object or language name that raised it. You can also turn on verbose logging (set log_min_error_statement=error and log_error_verbosity=verbose) or query pg_stat_activity to watch which statement invokes the extension before the failure. Knowing the precise function lets you open the source that issues the invalid SQLSTATE.

External routines in C call ereport() with errcode() (see the C-language function docs). Check the code path that raises the error; it might look like this snippet from the PostgreSQL documentation:

erreport(ERROR,
        (errmsg("something bad happened"),
         errcode(ERRCODE_FEATURE_NOT_SUPPORTED)));

If the code calls PG_SETERRCODE("some string") or a PL/pgSQL block uses RAISE ... USING ERRCODE = '39abc', the string must be exactly five uppercase alphanumeric characters. Any deviation is the cause of 39001.

Switch the routine to one of the macros defined in the errcodes appendix, or supply a valid five-character SQLSTATE string. For instance:

RAISE EXCEPTION 'invalid input' USING ERRCODE = '22000';

In C extensions, prefer macros such as ERRCODE_INVALID_PARAMETER_VALUE or a class-39 code like ERRCODE_EXTERNAL_ROUTINE_INVOCATION_EXCEPTION. These macros guarantee Postgres receives a recognized SQLSTATE, and they keep your extensions aligned with the official error catalog.

Once the SQLSTATE code is corrected, rebuild or reinstall the shared object (or redeploy the PL handler) and run the offending query again. A clean CREATE OR REPLACE FUNCTION, ALTER EXTENSION ... UPDATE, or server restart ensures the updated code path executes. Confirm that the same statement now either succeeds or raises a different, intentional SQLSTATE.