Re: [HACKERS] More on GROUP BY - Mailing list pgsql-hackers

Bruce Momjian wrote:

> The real problem is that it is hard to keep all these items synchronized
> as they pass around through the stages.  I looked at the aggregates, and
> it looks like that has a separate copy too, so it may not be that bad.
> We may just be missing a pass that makes appropriate changes in GROUP
> clauses, but I am not sure.

    Exactly  the probability of missing some changes somewhere is
    why  I  would  like  to  get  rid  of  the  field  entry   in
    GroupClause.  Having to keep duplicate items synced isn't the
    spirit of a relational database. It's like using triggers  to
    keep  two  tables in sync where a simple reference and a view
    would do a better job.

> > I think it's true that using a TLE for each grouplist item is a waste of
> > space, and that representing the grouplist as simply a list of expr's
> > would be good enough.  But pulling out the TLE decoration seems like
> > it's not an appropriate use of time at this stage of the release cycle.
> > I'd say hold off till after 6.5, then fold it in with the parsetree
> > redesign that you keep muttering we need (I agree!).
>
> Basically, it is my fault that I am bringing up the issue so late.  If I
> had done the Open Items list earlier, we would not be so close to the
> final.

    And my fault to spend too much time  playing  around  with  a
    raytracer.   Developers  should  develop,  publishers  should
    publish.

>
> Jan is currently researching it, and we have the regression tests and
> three weeks.  He usually does a fine job of fixing things.

    Thanks for the compliment :-)

>                                                            Jan, find
> out what you think is required to get this working, and if it is not too
> bad, maybe we should go ahead.
>
> What does the Aggreg do?  Does it has similar duplication?

    Not AFAICS. Aggregates can only appear in the  targetlist  by
    default.   and  the  nodes  below  them are the expression to
    aggregate over.  If an aggregate should appear in  the  WHERE
    clause  it  must  be placed into a proper subselect (the rule
    system already tries to do so if an aggregate column is  used
    in the WHERE of a view select, but fails sometimes).

    I'll go ahead now in little steps.

    1.  Get rid of the TLE copy in GroupClause.

    2.  Move the targetlist expansion into the rule system.

    3.  Rewrite the subquery creation for aggregates in the WHERE
        clause to take view grouping into account.

    4.  Allow qualifications against aggregates to  be  given  as
        "AggCol  op  Value"  by swapping the expression and using
        the negator operator (if one exists).

    As you said, we have three weeks. Let's see  what  one  Wieck
    can do in this time :-)


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