2011/1/2 Jim Nasby <j...@nasby.net> > > Renamed to fsnapshot. > > Is it actually limited to functions? ISTM this concept would be valuable > for anything that's not in pg_class (in other words, anything that doesn't > have user data in it). >
My ambition is to primarily support functions. Support for other object types are merely a necessary side-effect of the function dependencies. Is there a matrix of all possible object types dependencies? If not, for functions, is the following list correct? Object types which may depend on functions: constraints, views, triggers, any more? Functions may depend on: language, any more? Instead of limiting the support to functions, perhaps it would make more sense to limit it to all non-data objects? Is there a term for the group of object types not carrying any user data? Which object types do carry user data? I can only think of tables and sequences, any other? > Also, I'm not sure why this needs to be in contrib vs pgFoundry. > Good point. It's actually in neither of them right now, it's only at github.com :) I merely used the prefix contrib/ in the subject line to indicate it's not a patch to the "core". I do hope though it's possible to get a place for it in contrib/ at some time in the future, I think there is a chance quite a lot of users would appreciate a quicker, less error-prone way of handling these things. This tool must be made extremely reliable, otherwise you won't feel safe using it in a production environment for deployment and revert purposes, which is my company's requirement. I hope to achieve this by keeping a "bare minimum" approach to features, and making sure it only fulfills the objective: 1. take a snapshot of all non-data objects 2. <deploy code, test new code, or let time pass while other people make a mess in your database> 3. revert to previous snapshot without affecting any of the new data, generated in step 2 I put my faith in the reliability on system functions, such as pg_get_functiondef(), pg_get_viewdef() etc, to build proper create/drop commands for each object. Even nicer would be if the pg_catalog provided functions to generate SQL create/drop commands for all non-data object types, and to make sure _everything_ is included in the command, ensuring the object is created exactly the same, currently pg_get_functiondef() does not restore the ownership of the function, which I had to append manually. -- Best regards, Joel Jacobson Glue Finance
