On Jul 23, 2004, at 5:15 PM, Christopher Browne wrote:

> If you contribute code, that will presumably influence how it develops.

If I come up with anything worthwhile, I probably will. I'm personally 
partial to Perl-based solutions since I'm much more comfortable 
programming in Perl than in C, but I can understand the concerns of a 
broader community that doesn't want burdensome requirements.

> Good questions can be a good contribution, but are certainly a lesser
> influence.

Well, right. But there's nothing wrong with discussing the development 
process.

> I kind of like having a "belt and suspenders" approach; the more
> opportunities we have to allow avoiding mistakes, the better.
> Promoting mistakes by automagically copying every cruddy table over
> is, in effect, a promotion of mistakes.
>
> In a backup system, there typically need to be choices made as to what
> filesystems are to be backed up, possibly even what files.  This is a
> place where it seems to make sense to be even more precise about what
> is copied.

I understand this, but I think the evolution will probably be toward 
some level of automation, especially for enterprise deployments where 
there are thousands of tables.

> It is also possible that some tools will configure things based on
> running the stored procedures that are the _real_ basis for it all.  I
> spent a considerable chunk of this week contending with generating
> Slonik scripts, and I'm not certain it's "growing on me" :-(.
>
> I don't think anyone has final answers on any of this yet.

Fair enough. Thanks for the thoughtful responses.

-tfo