Re: [HACKERS] having bug report
От | José Soares |
---|---|
Тема | Re: [HACKERS] having bug report |
Дата | |
Msg-id | 3767C670.455DFAB2@sferacarta.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] having bug report (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
<font color="#000000">Sorry. I re-sent this message because I don't see it in TODO file and I thougth it was fixed.</font><p>TomLane ha scritto: <blockquote type="CITE">José Soares <jose@sferacarta.com> writes: <br />> *subqueries containing HAVING return incorrect results <br />> select istat from comuni where istat in ( <br />> selectistat from comuni group by istat having count(istat) > 1 <br />> ); <br />> ERROR: rewrite: aggregate columnof view must be at rigth side in qual <br />> select istat from comuni where istat in ( <br />> select istatfrom comuni group by istat having 1 < count(istat) <br />> ); <br />> ERROR: pull_var_clause: Cannot handlenode type 108 <p>These are both known problems (at least, I had both in my todo list). <p>The first one appears tobe a rewriter bug --- it seems to want to <br />implement count(istat) as a second nested sublink, and then it falls <br/>over because it doesn't handle "subselect op something" as opposed to <br />"something op subselect". But pushing count(istat)into a subselect <br />is not merely inefficient, it's *wrong* in this case because then the <br />group by won'taffect it. <p>The second one is a problem in the planner/optimizer; it falls over on <br />sublinks in HAVING clauses(of course, this particular example wouldn't <br />trigger the problem were it not for the upstream rewriter bug,but it's <br />still a planner bug). I think union_planner's handling of sublinks <br />needs considerable work, butwas putting it off till after 6.5. <p>I will work on the second problem; I think the first one is in Jan's <br />turf...<p> regards, tom lane</blockquote> Jose' <br />
В списке pgsql-hackers по дате отправления: