Re: BUG #19401: Inconsistent predicate evaluation with derived table vs direct query involving NULL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 2530254482(at)qq(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19401: Inconsistent predicate evaluation with derived table vs direct query involving NULL
Date: 2026-02-11 16:43:41
Message-ID: 4112620.1770828221@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> I would like to report a behavior that appears to be incorrect and
> inconsistent in PostgreSQL when the same predicate is evaluated in (1) a
> derived table and (2) a direct query.

> The two queries are logically equivalent, but they return different
> cardinalities.

> CREATE TABLE t0 (c0 TEXT);
> INSERT INTO t0 (c0) VALUES ('4');
> -- result: length 0;
> SELECT ref0 FROM (SELECT (any_value(c0)) AS ref0, ((('j' = NULL) <= (NULL =
> NULL))) AS ref1 FROM t0) AS s WHERE ref1;
> -- result: length 1; (NULL)
> SELECT (any_value(c0)) FROM t0 WHERE (('j' = NULL) <= (NULL = NULL));

These are not "logically equivalent". The first one applies the
WHERE filter above the aggregation, the second one applies it
before the aggregation. An aggregate will produce some value
(typically NULL) even if there are zero input rows, so the second
query gives a single NULL result as-expected. In the first query,
the subselect produces a row (4,NULL) but then the outer WHERE
filters that row away.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Rafia Sabih 2026-02-11 19:48:04 Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY
Previous Message PG Bug reporting form 2026-02-11 15:57:15 BUG #19401: Inconsistent predicate evaluation with derived table vs direct query involving NULL