Re: contrib/snapshot - Mailing list pgsql-hackers
| From | Joel Jacobson |
|---|---|
| Subject | Re: contrib/snapshot |
| Date | |
| Msg-id | AANLkTikaB840BkXgFvr82m6Gg-rG3K9yuzjYHyB5ZST+@mail.gmail.com Whole thread Raw |
| In response to | Re: contrib/snapshot (Jim Nasby <jim@nasby.net>) |
| Responses |
Re: contrib/snapshot
Re: contrib/snapshot |
| List | pgsql-hackers |
2011/1/2 Jim Nasby <jim@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
Best regards,
Joel Jacobson
Glue Finance
pgsql-hackers by date: