Thread: Add function dependencies
When a function is created, the system validates the syntax and complains if any function the created function attempts to call is missing. I think this is really good, since it traps typos and warns you if you have forgotten to install any functions your function depends on. It would be equally useful if it warned you when trying to drop a function other functions might depend on. Currently, I do something like SELECT * FROM pg_proc WHERE prosrc LIKE '%myfunc%' to verify nothing is using the function I'm about to drop. Just like you can disable the creation check by setting check_function_bodies to false, I would suggest a similar option to disable the check upon dropping functions, to disable the suggested dependency check. Additionally, if pg_depend would reveal function dependencies, it would be trivial to automatically generate function call digraphs in .dot format, showing a nice call tree of your entire system. -- Best regards, Joel Jacobson Glue Finance
On mån, 2011-01-10 at 23:59 +0100, Joel Jacobson wrote: > It would be equally useful if it warned you when trying to drop a > function other functions might depend on. This would only work for a small subset of cases, so the argument can be made that it is less surprising to say, we don't track dependencies of the function source code at all. Making it work for language SQL would be nice, though.
Peter Eisentraut <peter_e@gmx.net> writes: > Making it work for language SQL would be nice, though. Please consider a new DEPENDENCY_XXX constant for that though, because otherwise I think it could cause problems in the extension's dependency tracking. Even with a new DEPENDENCY_FUNCALL or other constant, the extension code would need to be aware of this new kind of not-to-follow dependencies somehow, I guess. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On tis, 2011-01-11 at 16:57 +0100, Dimitri Fontaine wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Making it work for language SQL would be nice, though. > > Please consider a new DEPENDENCY_XXX constant for that though, because > otherwise I think it could cause problems in the extension's dependency > tracking. Even with a new DEPENDENCY_FUNCALL or other constant, the > extension code would need to be aware of this new kind of not-to-follow > dependencies somehow, I guess. What's a "not-to-follow dependency"?
Peter Eisentraut <peter_e@gmx.net> writes: > What's a "not-to-follow dependency"? In case of extensions the code follows dependencies to walk on all objects. We already have the problem that an extension depending on another is not relocatable, because 'ALTER EXTENSION SET SCHEMA' would walk to objects of another extension (the one it depends on). We said inter-extension dependencies could wait until later, so what you do here is to declare your extension has not relocatable. Now, if there are some dependencies between objects that are not of the same extension, we have the exact same problem. That's what I called a "not-to-follow" dependency for lack of a better term. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> What's a "not-to-follow dependency"?
> In case of extensions the code follows dependencies to walk on all
> objects.
That seems pretty silly/broken. You should only be touching *direct*
dependencies of the extension, IMO. If there's something that's missed
by that algorithm, the way to fix it is to add more direct dependencies
at extension creation time; not to start a tree walk that is pretty
nearly guaranteed to land on things that don't belong to the extension.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > That seems pretty silly/broken. You should only be touching *direct* > dependencies of the extension, IMO. If there's something that's missed > by that algorithm, the way to fix it is to add more direct dependencies > at extension creation time; not to start a tree walk that is pretty > nearly guaranteed to land on things that don't belong to the extension. Well the current patch is walking the tree because that's what I need for listing extension's objects (in \dx ext), e.g. I want to follow from an opclass to its functions in that context. Now I reused this walker for ALTER EXTENSION SET SCHEMA, where it could well be that I don't need walking down the dependency tree. Will think about it and try it (very localised change). Thanks for comments. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Thanks to the new pg_stat_xact_user_functions and pg_stat_xact_user_tables views in 9.1, it will be possible to automatically "sample" which functions uses which functions/tables to generate a nice directional graph of the dependency tree, based on recent real-life activity, excluding any unused relations/functions not-in-use anymore. It's actually a feature to not include these, as they make the graph a lot more complicated. If you want a graph on the activity during Mondays between 2:30pm and 2:31pm, such a graph could easily be generated, or if you want it for 30 days (which would probably include a lot more edges in the graph), it can also be generated. :-) It would be quite easy to automatically inject some small code snippets to the top and bottom of each user function, to get the diff of select * from pg_stat_xact_user_functions and pg_stat_xact_user_tables between the entry point of each function and the exit point. It would be a lot nicer if it would be possible to automatically let PostgreSQL sample such data for you, providing nice system views with information on the sampled data per function, allowing you to query it and ask, - What functions has funciton public.myfunc(int) called and what tables has it inserted/selected/updated/deleted from since the last time I resetted the statistics? Just an idea... -- Best regards, Joel Jacobson Glue Finance