> > The historical information (RCS) is quite interesting. Is
> > there any chance that the 'Publishing' wizard will be able to
> > publish diffs between the database you're publishing to and
> > the test version(s)? As a step between these, the ability to
> > dump (in SQL form) the difference between one version and
> > another (that is, the commands to bring the
> > one up to the level with another) would be extreamly useful. Of
> > course, both have to be managable without any dataloss.
>
> Unfortunately this is not possible with the current system as the
revision
> control only stores the SQL to create the object, not what was used
to
> update it - which might not even be possible if it was modified in a
dump
> file or by dropping and recreating it.
>
> The only diff we could do would be a traditional text diff which
would be
> useless.
Sorry, I was making the assumption that the production database was
already identical to another version in the past. Ie. Production is
version 10, test is version 22. Could one not apply all statements
from 10 through 22 and end up with both databases being of the same
level?
As long as the alterations are non-destructive (ie. uses alter table
rather than dropping and re-creating the table while losing data)
which appears to be true. The only difference between a production,
test and development systems would be their current version. If the
RCS information was stored in each, it should be straight forward to
determine which was where.
I wonder if work has a copy of Visual Basic around somewhere. This is
a feature that benifits them quite a bit and it's about time I started
doing to some windows based development. Besides, I'd love to see the
thought behind my Postgresql Autodoc tool be integrated into PGAdmin.