Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions - Mailing list pgsql-bugs

From lindebg
Subject Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions
Date
Msg-id 4EC7E52F.1000509@gmail.com
Whole thread Raw
In response to Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #6301: extra space in psql variable expansion
Next
From: Tom Lane
Date:
Subject: Re: BUG #6299: pg_dump, pg_dumpall - Problem with the order of backup functions