Tom Lane-2 wrote
> bouda@
> writes:
>> A function may reference itself via default values of some of its
>> arguments.
>> It is rather tricky to create one, but it is possible:
>
> Unless you can demonstrate a credible use-case for this, I don't think
> it's worth adding complexity to pg_dump for.
Assuming: "Even worse, pg_dump returns 0 as the exit code, even though the
dump is not
usable. It merely issues a warning on output." is confirmed I would assume
that it would need to be fixed.
I'm not against simply letting pg_dump error out but it should do so
completely.
I imagine it would be reasonably simple to disallow CREATE FUNCTION to
reference the function being created in the default expressions but the
indirect circular dependency would definite be trickier. The uninformed
problem in both cases is dealing with function overloading - in addition to
simply tracking the cycle in the later scenario. But ideally we wouldn't
create something that pg_dump cannot restore...and not just allow pg_dump to
fail and figure that the user is going to test their restore code.
OTOH it is a function so unless itself is a dependency a warning would make
sense because the user, upon being informed of the issue, could manually
issue the same CREATE/REPLACE SQL command pair to re-construct the function
manually if they really need the capability.
David J.
--
View this message in context:
http://postgresql.nabble.com/BUG-12106-pg-dump-does-not-resolve-circular-dependency-tp5828685p5828698.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
