Re: [HACKERS] Re: [SQL] cursor and update + view

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) #