Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions
От | lindebg |
---|---|
Тема | Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions |
Дата | |
Msg-id | 4EC7E52F.1000509@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions
|
Список | pgsql-bugs |
On 11/19/2011 04:34 AM, Tom Lane wrote: > Color me skeptical. Under what conceivable use-case could you have > functions that were mutually dependent in that way? And actually did > something useful (not recurse till stack overflow) when called? > > regards, tom lane > Does this mean that this situation will not be handled by pg_dump / pg_restore? These functions do not cause a stack overflow: select fn1(); 3 select fn2(); 8 select fn3(); 5 select fn3(10); 10 It is not about to find now a practical example of use. There is always the possibility of finding another solution, without cyclical. But since PostgreSQL allows you to create such cyclically dependent functions, it should handle it in any case, also the pg_dump / pg_restore, or block the ability to create cycle-dependent functions. It's just my opinion. PostgreSQL is very good. I wish it was the most perfect. PS: Sorry if it hurt the language. I'm using Google Translate.
В списке pgsql-bugs по дате отправления: