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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #19401: Inconsistent predicate evaluation with derived table vs direct query involving NULL
Дата
Msg-id 4112620.1770828221@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #19401: Inconsistent predicate evaluation with derived table vs direct query involving NULL  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



В списке pgsql-bugs по дате отправления: