From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | "David Rowley" <dgrowley(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Windowing Function Patch Review -> Standard Conformance |
Date: | 2008-12-28 16:47:48 |
Message-ID: | 17581.1230482868@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> writes:
> 2008/12/28 David Rowley <dgrowley(at)gmail(dot)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 | 1
KITCHEN | COOKER | 1 | 2
KITCHEN | FRIDGE | 1 | 3
TABLE | CHAIR | 4 | 1
CHAIR | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-28 18:58:16 | Re: Windowing Function Patch Review -> Standard Conformance |
Previous Message | David Rowley | 2008-12-28 16:41:58 | Re: Windowing Function Patch Review -> Standard Conformance |