Re: Query with aggregate over subselects fails with ERROR: plan should not reference subplan's variable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Grace <dgrace(at)wingsnw(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Query with aggregate over subselects fails with ERROR: plan should not reference subplan's variable
Date: 2009-04-25 01:58:03
Message-ID: 23921.1240624683@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Daniel Grace <dgrace(at)wingsnw(dot)com> writes:
> On Fri, Apr 24, 2009 at 5:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Hmmm ... I guess something is getting confused about the level of query
>> nesting. FWIW, you can avoid the bug in these two examples by omitting
>> the inner "SELECT" keyword, which is useless anyway. Perhaps it is
>> needed in your real query though ...

> It's required in my case to force the aggregate function to evaluate its
> inputs in a set order.

Really? Your example doesn't show that.

> SELECT
> s.fid, c.flags, c.id, c.title, cs.ut_start, cs.ut_end, cr.full_name,
> cal.title AS cancel_reason,
> (SELECT GROUP_CONCAT((SELECT s2.fname FROM student AS s2 WHERE s2.id=
------
> s.id ORDER BY fname), '; ')) AS students,

I'm talking about the underlined SELECT, not the one inside the
aggregate. AFAICS this one is totally useless. If it were useful,
we'd likely have found this issue long ago ...

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2009-04-25 02:19:40 Re: Query with aggregate over subselects fails with ERROR: plan should not reference subplan's variable
Previous Message Daniel Grace 2009-04-25 00:58:11 Re: Query with aggregate over subselects fails with ERROR: plan should not reference subplan's variable