SQLSTATE 01003 is a warning that PostgreSQL inherits from the SQL standard whenever a set function (aggregate) skips NULL inputs. The query still returns a result, but the warning flags that nulls were silently removed so you can decide whether the missing values were expected.
SQLSTATE 01003 belongs to SQL standard class 01 (warning) and corresponds to the completion condition "warning- null value eliminated in set function". The SQL-92 spec specifies that when a "<value expression>" is applied to every row of a table and nulls are removed before computing the aggregate, that warning must be raised. PostgreSQL's built-in set functions (the general-purpose aggregates such as AVG, MAX, MIN, SUM, COUNT, and their ordered-set variants) always skip NULL inputs, so this warning simply acknowledges that at least one null row was discarded before the aggregation completed. Because PostgreSQL returns a result despite the warning, a client that promotes warnings to errors or logs SQLSTATE 01003 in detail is the only way you'll notice it.
Re-run the problematic aggregate while capturing notices/warnings from the server. For example:
CREATE TEMP TABLE t(id serial, d date);
INSERT INTO t(d) VALUES ('2025-01-01'), (NULL);
-- Postgres will still return the result, but a client that listens for warnings will
-- record SQLSTATE 01003 or the textual label null_value_eliminated_in_set_function.
SELECT MIN(d) FROM t;Check your session's client_min_messages setting if you do not see the warning: SHOW client_min_messages;. A driver that runs with warning or notice will log SQLSTATE 01003 when the NULL row is removed.
Use COUNT(*) FILTER (WHERE column IS NULL) or WHERE column IS NOT DISTINCT FROM NULL to count nulls in the aggregated input:
SELECT COUNT(*) FILTER (WHERE metric IS NULL) AS null_inputs,
COUNT(*) FILTER (WHERE metric IS NOT NULL) AS non_null_inputs
FROM payloads;If the null count is non-zero, the warning is expected: aggregates like MIN and MAX only see the non-null rows before emitting SQLSTATE 01003.
If nulls are not supposed to contribute to the aggregate anyway, make that explicit by filtering them with WHERE, FILTER, or CASE:
SELECT MIN(d) FILTER (WHERE d IS NOT NULL) AS earliest_date
FROM events;
-- or push the non-null predicate into the FROM clause
SELECT MIN(events.d)
FROM events
WHERE events.d IS NOT NULL;This removes the need for SQLSTATE 01003 because the aggregate no longer sees the NULL rows. When you still need to include NULLs but treat them as zero or a sentinel, wrap the aggregate result in COALESCE (for example, COALESCE(SUM(amount), 0)).
If the warning signals unexpected data quality, track down the producer of the NULL values (joins, ETL steps, etc.) and either prevent the nulls or translate them before aggregation. On the other hand, if NULLs are normal, log the warning at info level and keep client_min_messages at warning so you still see it in server logs without failing jobs. Some drivers convert SQLSTATE 01003 into exceptions; map that state back to a notice or ignore it explicitly so a meaningful result can still flow downstream.
PostgreSQL aggregates are βstrict,β meaning they ignore NULL inputs by design; SQLSTATE 01003 is only a reminder of that behaviour for tools that promote warnings. Unlike SQL Server, Postgres does not require toggling ANSI_WARNINGS, but the warning exists to satisfy the SQL-92 spec and to let you inspect whether NULL filtering is deliberate. When building cross-platform code, explicitly filter or translate NULLs before aggregation so both Postgres and other databases handle the data the same way.
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL
ERROR 42501: must be owner of table
How to fix "must be owner of table" in PostgreSQL
trigger cannot change partition destination
How to fix "Trigger cannot change partition destination" in PostgreSQL
vacuum failsafe triggered
How to fix "vacuum failsafe triggered" in PostgreSQL
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL