Re: [HACKERS] Views which lead to nested aggregates - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Views which lead to nested aggregates
Date
Msg-id 19086.930061830@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Views which lead to nested aggregates  (wieck@debis.com (Jan Wieck))
List pgsql-hackers
wieck@debis.com (Jan Wieck) writes:
>     Up  to  now  (v6.5)  this  kind  of  nested  aggregates isn't
>     supported.  Not directly over SQL, nor by views. To  be  sure
>     anything  is  fine,  your  views (and however you select from
>     them) should be expressable with a  regular  SELECT  too.  In
>     fact  the rewrite system has to try to build such a query for
>     it - so if you can't how should the rewriter can?

Still, it ought to either do it or produce a useful error message.
6.4's error message doesn't qualify as useful in my book.  But 6.5's
behavior is far worse: it accepts the query and cheerfully generates
a wrong result!  That's definitely a bug.

Looking ahead to the larger problem, I believe that the executor is
perfectly capable of handling nested aggregate plans --- the trick is
to get the planner to produce one.  Maybe we need an extension to the
parsetree language?  It doesn't seem like this ought to be hard to
support, it's just that there's no parsetree configuration that
represents what we want done.  Or, maybe we should rethink the division
of labor between the rewriter and planner --- if the rewriter could
output a partially-converted plan tree, instead of a parse tree, then
it could do as it pleased, but still leave the messy details of lowlevel
plan optimization to the planner.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Guillaume Lairloup
Date:
Subject: ...
Next
From: Jeff Hoffmann
Date:
Subject: Re: [HACKERS] has anybody else used r-tree indexes in 6.5?