Re: Windowing Function Patch Review -> Standard Conformance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Windowing Function Patch Review -> Standard Conformance
Date
Msg-id 17581.1230482868@sss.pgh.pa.us
Whole thread Raw
In response to Re: Windowing Function Patch Review -> Standard Conformance  ("Hitoshi Harada" <umi.tanuki@gmail.com>)
Responses Re: Windowing Function Patch Review -> Standard Conformance  ("David Rowley" <dgrowley@gmail.com>)
List pgsql-hackers
"Hitoshi Harada" <umi.tanuki@gmail.com> writes:
> 2008/12/28 David Rowley <dgrowley@gmail.com>:
>> I've started running my test queries that I used when reviewing the patch.
>> The following crashes the backend:

> It seems that parseCheckWindowFuncs() doesn't check CTE case whereas
> parseCheckAggregates() checks it, including check of window functions.
> So the urgent patch is as following, but is this operation allowed? I
> am blind in CTE rules...

Well, this certainly demonstrates that the check I added to
parseCheckAggregates is wrongly placed, but I'm not sure we really
need to forbid the case.  David's example query seems to give sane
answers once the bug in begin_partition is fixed:
parentpart | childpart | quantity | rn 
------------+-----------+----------+----KITCHEN    | TABLE     |        1 |  1KITCHEN    | COOKER    |        1 |
2KITCHEN   | FRIDGE    |        1 |  3TABLE      | CHAIR     |        4 |  1CHAIR      | LEG       |        4 |  1
 
(5 rows)

I basically went around and made sure everyplace that threw an
error for aggregates also threw one for window functions, but
it's quite possible that that's overly restrictive in some places.
Window functions don't cause grouping so there's no reason to
forbid them in places where it's the grouping behavior that
is objectionable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "David Rowley"
Date:
Subject: Re: Windowing Function Patch Review -> Standard Conformance
Next
From: Tom Lane
Date:
Subject: Re: Windowing Function Patch Review -> Standard Conformance