The combination of perl and slonik seems pretty powerful to me, allowing
perl to do the procedural heavy lifting and leaving replication/database
operations to slonik. I think with a "little languages" like slonik
there is always the point at which you want to start adding procedural
constructs, more complex variables, etc., but it can be a slippery slope
and there is a potential to end up re-implementing a lot of
functionality which was already available in standard scripting
languages.

The slony_setup.pl is certainly more monolithic than it needs to be, but
it's early days for this excellent project, and as a starting place it
has been very helpful to me over the past few days, so I'm glad to have
it! I would definitely welcome a set of more granular perl-based tools -
maybe eventually a perl interface to slonik?

As far as configuration/build of slony itself, I would wonder about
moving away from configure, etc., just because it is used in so many
projects, most importantly postgres itself, of course, and people are
used to it. The times I've had to actually modify configure.in files for
porting purposes have been pretty painful, so I'm no fan of configure,
but it does work...mostly. I'm not sure if that was what was intended by
the original post.

- DAP

-----Original Message-----
From: slony1-general-bounces at gborg.postgresql.org
[mailto:slony1-general-bounces at gborg.postgresql.org] On Behalf Of
Christopher Browne
Sent: Thursday, July 22, 2004 10:35 AM
To: Thomas F.O'Connell
Cc: slony1-general at gborg.postgresql.org
Subject: Re: [Slony1-general] Table Selection

Thomas F. O'Connell <tfo at sitening.com> writes:
> On Jul 18, 2004, at 10:57 PM, Christopher Browne wrote:
>
>> I have a set of Perl scripts for controlling a cluster that I'll be 
>> checking in Real Soon Now.
>>
>> Unlike the monolithic script that is in the distribution now that 
>> asks all sorts of questions, my toolset grabs cluster config from a 
>> config file, and then has a script for each of a variety of major 
>> actions you'd want to invoke on the cluster.  It doesn't yet include 
>> scripts for shifting the origin; that will presumably come soon 
>> enough...
>
> So this doesn't fully answer my question about the status of slonik. 
> Has the concept of a set of Perl scripts met with wider developer and 
> community approval? Does it make the most sense for propagation of 
> Slony in terms of it becoming the generally accepted (or one of the 
> generally accepted) replication solutions for postgres?  I'm not 
> trying to be antagonistic; I'm just trying to understand the 
> development process and rationale and play a bit of devil's advocate.

My intent is to throw another choice up against the wall, so we can see
what's going to stick better.

>> One of the assumptions is that there will be, available, a list of 
>> all of the relevant relations that are to be replicated.
>
> Available to the script or made available by the script?

Available TO the script.

>> I don't see any way to generalize that in any "vast" way.
>
> Just based on my limited exposure to and use of slony thus far, I 
> would think it wouldn't be too nonsensical to have slonik commands 
> that correspond to your sets as outlined below:
>
>> My assumption
>> is that the lists exist as the following sets:
>>
>>  - A list of tables that have primary key candidates;
>>
>>  - A list of tables for which Slony-I will need to add a primary key 
>> candidate;
>>
>>  - A list of sequences that are to be replicated.
>
> For instance, why not create slonik commands like
>
> SET ADD UNIQUELY CONSTRAINED TABLES
> SET ADD UNCONSTRAINED TABLES
> SET ADD ALL TABLES
> SET ADD ALL SEQUENCES

Because there may be some table that SHOULDN'T be replicated.

In our applications, for instance, there are all the tables that are
"officially" part of the server application, and then there are some
utility tables that the DBAs periodically create when looking to repair
some problem that has occurred.

If we said "replicate all tables," that would include cruddy ones that
perhaps should be thrown away.

A better approach would be to request all tables in a particular
namespace, as it is somewhat more likely that a namespace will be kept
clean.

>> Stick those three things in a config file, and it's dead easy to 
>> generate a suitable "create set" that first adds PK candidates and 
>> then builds the set of all the tables.

> Again, my point would be why not (plan to) have slonik handle this 
> work for you?

Because it may take human planning to get this to all take place at an
appropriate time.

For instance, suppose the database is rather large, and you have to very
carefully schedule when the "unique key" creation will take place on
some critical table, because that will lead to an application outage.
In that case, having slonik "magically handle this" would be downright
undesirable.

>> If you have thousands of relations, you'll probably need to build 
>> queries to look for them.  At that point, throwing them into a file 
>> should be no big deal.
>
> Yeah, that's what I'm currently working on.
>
>> I would be reluctant to add functionality to try to do that 
>> automagically; the more sophisticated scripts get, the more their 
>> actions resemble magick, and the more difficult it is to convince a 
>> DBA to trust them :-(.
>
> Well, isn't programming in general just scripting writ a bit larger?
> I mean, what's the difference between a slonik command that grabs all 
> user relations and postgres itself in general. If a DBA trusts the 
> DBMS, then the DBA ought to be able to have some trust in the extended

> development community that organizes around the DBMS.

That only works if we're looking at:
 - Development in the small, where everyone knows everyone, and
 - Development under a tightly controlled set of DB management
   doctrines.

If there's any reason to need to be _careful_ about what data gets
replicated, then magick becomes a major misfeature.
--
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@"
[name;tld];; <http://dev6.int.libertyrms.com/> Christopher Browne
(416) 673-4124 (land)
_______________________________________________
Slony1-general mailing list
Slony1-general at gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/slony1-general