Re: BUG #16900: SELECT MAX subquery not allowed in WHERE clause when using WITH RECURSIVE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: dan(dot)farlow(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16900: SELECT MAX subquery not allowed in WHERE clause when using WITH RECURSIVE
Date: 2021-02-26 16:40:13
Message-ID: 287738.1614357613@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> CREATE TABLE IF NOT EXISTS
> Tasks (task_id int, subtasks_count int);
> ...

> UNION ALL
> SELECT
> task_id, max_subtask_count, subtask_id + 1
> FROM
> possible_tasks_subtasks
> -- using SELECT MAX in the WHERE clause below is what causes the error
> WHERE
> subtask_id < (SELECT MAX(max_subtask_count) FROM Tasks))

max_subtask_count is not a field of Tasks; perhaps you meant to
write MAX(subtasks_count)?

As the query is written, the aggregate is over a field of
possible_tasks_subtasks, making it illegal in WHERE, just
as the error says. (From the point of view of the "SELECT FROM Tasks"
subquery, it's a constant outer reference, not an aggregate of
that subquery. This is per SQL spec.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-02-26 16:55:56 Re: BUG #16901: log(1, anyvalue) gives division by zero error
Previous Message Tom Lane 2021-02-26 16:35:36 Re: Upgrade issue during Postgres 9.6 to 12.3 on the two and more server