How to fix 01003: null_value_eliminated_in_set_function in PostgreSQL

PostgreSQLBEGINNERLOWUpdated Dec 22, 2025· 135 views

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.

Quick fix

Fixes 01003: null_value_eliminated_in_set_function

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;
  1. Confirm SQLSTATE 01003 is the message you are seeing
  2. Audit the data to see which columns are nullable
  3. Filter or coalesce the NULLs before aggregation
  4. Document and handle NULL propagation in upstream code
postgresql — error
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;
01003: null_value_eliminated_in_set_function

What this error means

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.

Typical symptoms

  • The query completes but the client logs/tells you "01003: null_value_eliminated_in_set_function"
  • psql, ORM, or driver output mentions a warning or notice level record with SQLSTATE 01003
  • Aggregate queries such as MIN, MAX, AVG, SUM, or JSON/array aggregations only see a subset of rows (the non-null ones)
  • Window functions, ordered-set aggregates, or grouping expressions that feed on nullable columns surface the warning in logs
  • ETL or reporting pipelines that treat warnings as failures get interrupted even though the computed result looks correct

Common causes

  1. The aggregated column contains NULL values, and the strict aggregate silently filters them before combining the rest
  2. Window or ordered-set aggregates run over partitions that include NULL cells that are removed by the aggregation logic
  3. A computed column, trigger, or client expression produces NULL and then hands it to an aggregate that drops it
  4. Client libraries or drivers (ODBC/JDBC/psql) propagate SQLSTATE 01003 as a warning because the warning level is not suppressed
  5. Cross-platform migrations, where SQL Server's ANSI_WARNINGS/SET ANSI_NULLS causes the same behaviour to be surfaced as a warning instead of being ignored

How to fix "01003: null_value_eliminated_in_set_function"

1Confirm SQLSTATE 01003 is the message you are seeing

Re-run the problematic aggregate while capturing notices/warnings from the server. For example:

sql
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.

2Audit the data to see which columns are nullable

Use COUNT(*) FILTER (WHERE column IS NULL) or WHERE column IS NOT DISTINCT FROM NULL to count nulls in the aggregated input:

sql
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.

3Filter or coalesce the NULLs before aggregation

If nulls are not supposed to contribute to the aggregate anyway, make that explicit by filtering them with WHERE, FILTER, or CASE:

sql
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)).

4Document and handle NULL propagation in upstream code

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.

Advanced notes

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.

Frequently asked questions

What does "01003: null_value_eliminated_in_set_function" mean?
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.
How do I fix "01003: null_value_eliminated_in_set_function"?
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.
What causes "01003: null_value_eliminated_in_set_function"?
The aggregated column contains NULL values, and the strict aggregate silently filters them before combining the rest Window or ordered-set aggregates run over partitions that include NULL cells that are removed by the aggregation logic A computed column, trigger, or client expression produces NULL and then hands it to an aggregate that drops it
Is the "01003: null_value_eliminated_in_set_function" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading