Re: [SQL] HAVING in EXISTS-clause ...
От | Tom Lane |
---|---|
Тема | Re: [SQL] HAVING in EXISTS-clause ... |
Дата | |
Msg-id | 13557.942292816@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [SQL] HAVING in EXISTS-clause ... (Stuart Rison <rison@biochemistry.ucl.ac.uk>) |
Ответы |
Re: [SQL] HAVING in EXISTS-clause ...
|
Список | pgsql-sql |
Stuart Rison <rison@biochemistry.ucl.ac.uk> writes: > It's just a case of reversing the order of the aggregate and the constant > in your qualifier (as hinted to by the error message). > This worked for me > SELECT [DISTINCT] AO,AT,AV FROM P3AT AS OAT > WHERE > EXISTS( > SELECT AO FROM P3AT > WHERE > AO = OAT.AO > GROUP BY AO > HAVING 8 = COUNT(*) > ); Marten has actually stumbled across a bug here: the rewriter mistakenly thinks that COUNT() appears in the outer SELECT's WHERE clause (well, it does, but since it's inside a sub-select it really belongs to the inner SELECT) and is trying to rewrite the query to push the COUNT() into yet a third level of SELECT. That doesn't hurt in this case, but in other cases it generates the wrong answer. The "must be at right side in qual" message appears because the rewriter only knows how to push down COUNT() on the right side of an operator. That's a pretty bogus limitation, but the whole thing is really pretty bogus --- none of that rewriter code would exist if we could handle views involving aggregate functions as sub-selects in FROM. So it's probably not worth any effort to add more code to a routine that shouldn't exist in the first place; we've got to work on the fundamental problem instead. regards, tom lane
В списке pgsql-sql по дате отправления: