PostgreSQL Warning (SQLSTATE 01000): What It Means and How to Handle It

When PostgreSQL issues a non-fatal advisory message that does not belong to a more specific warning subclass, you will see a message with severity WARNING and SQLSTATE 01000. The condition name for this SQLSTATE is WARNING. Unlike errors, warnings do not abort the current statement or transaction — execution continues normally after the warning is emitted.

What This Error Means

SQLSTATE codes in PostgreSQL are five characters long. The first two characters identify the class: class 01 is the Warning class. SQLSTATE 01000 is the "catch-all" warning within that class — it is used when the situation warrants a warning but does not match any of the named subclasses such as 01003 (null_value_eliminated_in_set_function), 01007 (privilege_not_granted), or 0100C (dynamic_result_sets_returned).

Warnings are generated by the PostgreSQL server and sent to the client as a NOTICE-level message with severity WARNING. They appear in psql output, application logs, and are returned in the message queue alongside query results. The current statement completes successfully; no transaction rollback occurs as a result of a warning alone.

Custom PostgreSQL functions and procedures written in PL/pgSQL can also emit 01000 explicitly using RAISE WARNING without a condition name, or by raising the generic WARNING condition. This is a common pattern for surfacing advisory information without disrupting the caller.

Common Causes

1. RAISE WARNING in PL/pgSQL without a specific condition. When a stored function or procedure calls RAISE WARNING 'some message' with no USING ERRCODE, PostgreSQL assigns SQLSTATE 01000. This is the most frequent source of 01000 in production systems.

2. Server-side implicit type coercion or truncation. In some older PostgreSQL versions or with certain server configuration options, the engine emits a generic warning when an implicit conversion loses precision (though more specific SQLSTATEs are usually assigned in modern versions).

3. Extensions or procedural languages raising generic warnings. Third-party extensions implemented in C that call ereport(WARNING, ...) without a specific SQLSTATE will default to 01000.

4. DO blocks issuing diagnostic output. Anonymous DO blocks using RAISE WARNING are a common way to emit status messages during migrations or maintenance scripts.

How to Fix WARNING

Because 01000 is a generic warning class rather than an error, "fixing" it usually means deciding how your application should handle it rather than eliminating the root problem.

1. In PL/pgSQL, assign a specific SQLSTATE if the warning has a well-defined meaning. This makes warnings easier to handle programmatically in calling code:

   -- Less specific: defaults to 01000
   RAISE WARNING 'Deprecated parameter ignored: %', param_name;
   
   -- More specific: custom SQLSTATE in the warning class
   RAISE WARNING 'Deprecated parameter ignored: %' USING ERRCODE = '01000';
   

2. Capture warnings in your application driver. Most drivers expose warnings from the server alongside the result set. In Python with psycopg2 or psycopg3, you can inspect connection.notices:

   import psycopg2
   
   conn = psycopg2.connect(dsn)
   cur = conn.cursor()
   cur.execute("SELECT my_function()")
   for notice in conn.notices:
       print("PostgreSQL notice:", notice)
   

   In Java (JDBC), use Statement.getWarnings() to retrieve a SQLWarning chain after executing a statement.

3. Log and monitor warnings from migration scripts. When running DO blocks or function-heavy migrations, redirect psql output to a log file and review warnings:

   psql -v ON_ERROR_STOP=1 -f migration.sql 2>&1 | tee migration.log
   grep -i warning migration.log
   

4. Suppress specific RAISE WARNING calls during testing if they are expected. In PL/pgSQL test suites (e.g., pgTAP), you can wrap calls in exception blocks or adjust client_min_messages for the session:

   SET client_min_messages = ERROR;
   -- Warnings will no longer be sent to the client
   SELECT my_function_that_warns();
   RESET client_min_messages;
   

5. Identify the source of unexpected warnings. If you are seeing 01000 warnings you did not expect, enable log_min_messages = warning in postgresql.conf (or ALTER SYSTEM SET log_min_messages = 'warning') and check the PostgreSQL server logs for the full message text and the function or query that generated it.

Additional Information

• The 01 warning class has existed since PostgreSQL's earliest versions. Class 01 is defined in the SQL standard; PostgreSQL's mapping is consistent with it.
• Related SQLSTATE codes in class 01 include: 01003 (null_value_eliminated_in_set_function), 01004 (string_data_right_truncation), 01006 (privilege_not_revoked), 01007 (privilege_not_granted), 0100C (dynamic_result_sets_returned), 01P01 (deprecated_feature).
• The PostgreSQL client_min_messages GUC controls which severity levels are transmitted to the client. Setting it to ERROR suppresses warnings in the client session without affecting server-side logging.
• In PL/pgSQL, RAISE WARNING is equivalent to RAISE with LEVEL WARNING. The condition WARNING (SQLSTATE 01000) is listed in the PostgreSQL error condition table.
• ORMs such as SQLAlchemy emit Python warnings.warn() calls when they receive server-side WARNING messages; these appear in application logs as SAWarning entries.

Frequently Asked Questions

Will a 01000 warning roll back my transaction? No. Warnings in class 01 are purely informational. The statement that triggered the warning completes normally, and the transaction remains open and unaffected. Only errors (SQLSTATE classes 02 through HZ and P0) can cause statement or transaction failure.

How do I tell which function or query produced the warning? Enable log_min_messages = 'warning' on the server and check postgresql.log. Each warning log entry includes the function name, line number (for PL/pgSQL), and the full message text. You can also set PG_DEBUG or use pg_query_settings to trace execution paths in development environments.

My application is silently discarding warnings — how do I capture them? Most database drivers buffer server notices separately from query results. Check your driver's documentation: in psycopg2 use connection.notices, in asyncpg register a add_log_listener callback, in JDBC call Statement.getWarnings(), and in Node.js pg listen to the notice event on the client object.

Can I raise a 01000 warning from a plain SQL function (not PL/pgSQL)? No. RAISE is a PL/pgSQL statement and is not available in plain SQL functions. To emit warnings from plain SQL, wrap the logic in a PL/pgSQL DO block or stored procedure. Extensions written in C can call ereport(WARNING, ...) directly.