Re: Windowing Function Patch Review -> Standard Conformance

From: "David Rowley" <dgrowley(at)gmail(dot)com>
To: "'Hitoshi Harada'" <umi(dot)tanuki(at)gmail(dot)com>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windowing Function Patch Review -> Standard Conformance
Date: 2008-12-28 16:41:58
Message-ID: 7E91B6FB66504337A842D7C4F2961558@amd64
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-28 16:47:48 Re: Windowing Function Patch Review -> Standard Conformance
Previous Message Tom Lane 2008-12-28 16:27:17 Re: Windowing Function Patch Review -> Standard Conformance