Re: Windowing Function Patch Review -> Standard Conformance

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Windowing Function Patch Review -> Standard Conformance
Дата
Msg-id 7E91B6FB66504337A842D7C4F2961558@amd64
обсуждение исходный текст
Ответ на Re: Windowing Function Patch Review -> Standard Conformance  ("Hitoshi Harada" <umi.tanuki@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Windowing Function Patch Review -> Standard Conformance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Windowing Function Patch Review -> Standard Conformance