Thread: Dependency tracking tool
Hello, In order to have a "global map" of the dependencies of the functions, views, tables in a PG database, I'd like to have some sort of "dependency tracking tool", that would show for each object: - which other objects depend on this object - on which other objects this object depends This would for example show that a table T1 has a trigger that depends on a trigger function F1 which itself depends on another function F2 that updates table T2, or that function F2 has a dependent trigger function F1 linked to a table T1, and that it updates table T2, etc... Is it correct to say that this "hierarchy" does not exist inside Postgresql, and that it is necessary to parse the INFORMATION_SCHEMA.* tables to get this information? Because of function overloading allowed in PG, I guess it is not an easy job. Does such a tool exist maybe? Best regards, Philippe ----------------------------------------------------------------------- Philippe Lang Web : www.attiksystem.ch Attik System Email : philippe.lang@attiksystem.ch rte de la Fonderie 2 Phone : +41 26 422 13 75 1700 Fribourg Mobile : +41 79 351 49 94 Switzerland Fax : +41 26 422 13 76
"Philippe Lang" <philippe.lang@attiksystem.ch> writes:
> In order to have a "global map" of the dependencies of the functions,
> views, tables in a PG database, I'd like to have some sort of
> "dependency tracking tool", that would show for each object:
> - which other objects depend on this object
> - on which other objects this object depends
You can find the raw data for that in pg_depend; at least for the sorts
of dependencies that PG cares about, which might not be exactly what you
are looking for. In particular we do not try to track what objects the
code inside a function might refer to.
> Is it correct to say that this "hierarchy" does not exist inside
> Postgresql, and that it is necessary to parse the INFORMATION_SCHEMA.*
> tables to get this information?
The information_schema views do not expose that information at all.
regards, tom lane
Philippe Lang wrote: > Hello, > > In order to have a "global map" of the dependencies of the functions, > views, tables in a PG database, I'd like to have some sort of > "dependency tracking tool", that would show for each object: > > - which other objects depend on this object > - on which other objects this object depends Greg Stark published an example query here http://www.pgcon.org/2009/schedule/events/181.en.html -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Tom wrote: >> In order to have a "global map" of the dependencies of the functions, >> views, tables in a PG database, I'd like to have some sort of >> "dependency tracking tool"... >> >> <snip> >> >> Is it correct to say that this "hierarchy" does not exist inside >> Postgresql, and that it is necessary to parse the >> INFORMATION_SCHEMA.* tables to get this information? > > The information_schema views do not expose that information at all. The information schema exposes at least the functions definitions, through "INFORMATION_SCHEMA.routines.routine_definition". My idea was to parse the functions definitions in order to build dependencies between the functions. I'm not sure how difficult it is, especially with overloaded functions, which require more than a simple pattern search inside the function definition in order to be distinguished... Best regards, ----------------------------------------------------------------------- Philippe Lang Web : www.attiksystem.ch Attik System Email : philippe.lang@attiksystem.ch rte de la Fonderie 2 Phone : +41 26 422 13 75 1700 Fribourg Mobile : +41 79 351 49 94 Switzerland Fax : +41 26 422 13 76
On mån, 2009-12-14 at 16:58 +0100, Philippe Lang wrote: > My idea was to parse the functions definitions in order to build > dependencies between the functions. I'm not sure how difficult it is, > especially with overloaded functions, which require more than a simple > pattern search inside the function definition in order to be > distinguished... In the general case, this will ultimately be equivalent to solving the halting problem.