Amit Kapila <amit.kapil...@gmail.com> writes:
> On Tue, Dec 10, 2013 at 12:15 PM, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
>> Now, PG has no any tool for checking dependency between functions and other
>> objects.
> Isn't that already done for SQL function's (fmgr_sql_validator)?
Pavel's point is that the only way to find out if the validator will fail
is to run it and see if it fails; and even if it does, how much will you
know about why? That's not particularly helpful for pg_dump, which needs
to understand dependencies in a fairly deep fashion. It not only needs to
figure out how to dump the database objects in a dependency-safe order,
but what to do to break dependency loops.
Right now I believe that pg_dump has a workable strategy for every
possible case of circular dependencies, because they are all caused by
secondary attributes of objects that can be split out and applied later,
for example applying a column default via ALTER TABLE ALTER COLUMN SET
DEFAULT rather than listing the default right in the CREATE TABLE command.
However, if function A depends on B and also vice-versa (mutual recursion
is not exactly an unheard-of technique), there is no way to load them both
if the function bodies are both checked at creation time.
I guess we could invent some equivalent of a forward declaration, but
that still leaves us short of understanding what the function body is
depending on.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
