Re: Should we have an optional limit on the recursion depth of recursive CTEs?

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Should we have an optional limit on the recursion depth of recursive CTEs?
Дата
Msg-id CAM-w4HPAf7Tfj9Y+TmnG=UaFFhL0Y=y1VEmDH08W4CeaiATHhA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should we have an optional limit on the recursion depth of recursive CTEs?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs?  (Magnus Hagander <magnus@hagander.net>)
Re: Re: Should we have an optional limit on the recursion depth of recursive CTEs?  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... and that would be a seriously bad API.  There are not SUSET
> restrictions on other resources such as work_mem.  Why do we need
> one for this?

I think a better analogy would be imposing a maximum number of rows a
query can output. That might be a sane thing to have for some
circumstances but it's not useful in general.

Consider for instance my favourite recursive query application,
displaying the lock dependency graph for pg_locks. What arbitrary
maximum number of locks would you like to impose at which the query
should error out?

There is a situation though that I think is motivating this though
where it would be nice to detect a problem: when the query is such
that it *can't* produce a record because there's an infinite loop
before the first record. Ideally you want some way to detect that
you've recursed and haven't changed anything that could lead to a
change in the recursion condition. But that seems like a pretty hard
thing to detect, probably impossible.


--
greg


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: walprotocol.h vs frontends
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: walprotocol.h vs frontends