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

From David Rowley
Subject Re: Windowing Function Patch Review -> Standard Conformance
Date
Msg-id 7E91B6FB66504337A842D7C4F2961558@amd64
Whole thread Raw
In response to Re: Windowing Function Patch Review -> Standard Conformance  ("Hitoshi Harada" <umi.tanuki@gmail.com>)
List pgsql-hackers
Hitoshi Harada wrote:
> > WITH RECURSIVE bom AS (
> >  SELECT parentpart,childpart,quantity,ROW_NUMBER() OVER (ORDER BY
> > parentpart DESC) rn
> >  FROM billofmaterials
> >  WHERE parentpart = 'KITCHEN'
> >  UNION ALL
> >  SELECT b.parentpart,b.childpart,b.quantity,ROW_NUMBER() OVER (ORDER BY
> > parentpart ASC) rn
> >  FROM billofmaterials b
> >  INNER JOIN bom ON b.parentpart = bom.childpart
> > )
> > SELECT * from bom;
> >
> > It seems not to like recursively calling row_number(). It does not crash
> if
> > I replace the 2nd row_number() with the constant 1
> >
>
> 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...
>
>

I should have said that this is the first time I've seen a crash running
this query.

I only ever ran this query to verify that the backend didn't crash. I didn't
ever pay much attention to the results. Do you have an older version that
you can verify if it worked as it should have or not?

Your final version won't patch with CVS head anymore.

David



pgsql-hackers by date:

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