having bug report

Started by José Soaresover 26 years ago3 messages
#1José Soares
jose@sferacarta.com

* subqueries containing HAVING return incorrect results

select istat from comuni where istat in (
select istat from comuni group by istat having count(istat) > 1
);
ERROR: rewrite: aggregate column of view must be at rigth side in qual

select istat from comuni where istat in (
select istat from comuni group by istat having 1 < count(istat)
);
ERROR: pull_var_clause: Cannot handle node type 108

______________________________________________________________
PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: José Soares (#1)
Re: [HACKERS] having bug report

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

* subqueries containing HAVING return incorrect results
select istat from comuni where istat in (
select istat from comuni group by istat having count(istat) > 1
);
ERROR: rewrite: aggregate column of view must be at rigth side in qual
select istat from comuni where istat in (
select istat from comuni group by istat having 1 < count(istat)
);
ERROR: pull_var_clause: Cannot handle node type 108

These are both known problems (at least, I had both in my todo list).

The first one appears to be a rewriter bug --- it seems to want to
implement count(istat) as a second nested sublink, and then it falls
over because it doesn't handle "subselect op something" as opposed to
"something op subselect". But pushing count(istat) into a subselect
is not merely inefficient, it's *wrong* in this case because then the
group by won't affect it.

The second one is a problem in the planner/optimizer; it falls over on
sublinks in HAVING clauses (of course, this particular example wouldn't
trigger the problem were it not for the upstream rewriter bug, but it's
still a planner bug). I think union_planner's handling of sublinks
needs considerable work, but was putting it off till after 6.5.

I will work on the second problem; I think the first one is in Jan's
turf...

regards, tom lane

#3José Soares
jose@sferacarta.com
In reply to: Tom Lane (#2)
Re: [HACKERS] having bug report

Sorry. I re-sent this message because I don't see it in TODO file and I
thougth it was fixed.

Tom Lane ha scritto:

=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com> writes:

* subqueries containing HAVING return incorrect results
select istat from comuni where istat in (
select istat from comuni group by istat having count(istat) > 1
);
ERROR: rewrite: aggregate column of view must be at rigth side in qual
select istat from comuni where istat in (
select istat from comuni group by istat having 1 < count(istat)
);
ERROR: pull_var_clause: Cannot handle node type 108

These are both known problems (at least, I had both in my todo list).

The first one appears to be a rewriter bug --- it seems to want to
implement count(istat) as a second nested sublink, and then it falls
over because it doesn't handle "subselect op something" as opposed to
"something op subselect". But pushing count(istat) into a subselect
is not merely inefficient, it's *wrong* in this case because then the
group by won't affect it.

The second one is a problem in the planner/optimizer; it falls over on
sublinks in HAVING clauses (of course, this particular example wouldn't
trigger the problem were it not for the upstream rewriter bug, but it's
still a planner bug). I think union_planner's handling of sublinks
needs considerable work, but was putting it off till after 6.5.

I will work on the second problem; I think the first one is in Jan's
turf...

regards, tom lane

Jose'