Re: contrib/snapshot

2011/1/2 Jim Nasby <jim(at)nasby(dot)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