Vadim wrote:
>
> Jan Wieck wrote:
> >
> > > My other problem is with the views: it seems not work if there is an
> > > aggregate command in the SELECT. It's only my experience, or others
> > > noticed it also? (The details are on the pgsql-novice (subject: view
> > > and aggregate command problem))
> >
> > Aggregates in view's are still buggy. It is possible to
> > change the grouping when doing a join from such a view and
> > another relation in a way, that crashes the backend.
>
> We'll have to implement subqueries in FROM someday - this would
> allow handle aggregates in views...
You're right. In the current implementation, any rangetable
entry (RTE) that is finally (after rewrite) used in any Var
node of the querytree results in a scan of that relation.
Having an RTE that contains its own subquery would
materialize the view internally and help us out.
This kind of subquery RTE will also be the base for functions
that return result sets (SETOF complex type). These are
broken too.
It will be a little tricky to pull out the qualifications
that restrict the subquery RTE, so the view must not entirely
get materialized. At least any constant expression compared
against one of the views attributes must go into.
There is another thing that I would like to have. The current
rule system tries to turn a qualification that uses an
aggregate column of a view into a subquery. This is because
the planner doesn't support plain aggregate expressions in
the qualification. If it would be possible to have another
type of Var node that points to a targetlist entry, we could
put the aggregates from the qualification into junk TLE's.
TGL - are you listening - I think it's your code I'm ulyfying
here :-).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
