On Wed, 16 Mar 2005, Christopher Browne wrote:

> 0.  I agree with Josh that it's probably a bad idea to mangle pg_dump
>    output because you can't depend on its ordering.
>
>    His comment that the format "*will* change" isn't actually strong
>    enough; it's fair to say that Slony-I needs to support multiple
>    formats _already_ because the formats differ between 7.3, 7.4, and
>    8.0 due to the very same issue of relational dependancies.

Yep, I'm not happy with this, and will be looking at pg_depend, as Josh 
suggested.  It *does* appear to work in 7.4 and 8.0.  I don't have any 
machines running 7.3 any more, so I haven't tested that case.

For now, I'm wondering if this is "commit"able with a TODO item, or not at 
all.  It's certainly useful to me, and I'll be keeping a copy of it 
regardless, but it would be easier if it were in CVS, especially if it's 
something that others will use.

> 1.  You might also take a look at Jan's script "slony1_dump.sh", in
>    the tools directory, which prepares a log shipping schema.

Did you mean the slony1_extract_schema.sh script?  slony1_dump.sh just does 
data, according to its header.

Looking at slony1_extract_schema.sh, it does the entire database, rather 
than a single set, which is the purpose of this change.  As an example, I 
have five sets in a cluster, and have already subscribed three of them.  I 
only want to copy the schema I need for the fourth set, rather than 
everything.

> 2.  I would think the more parsimonious approach would be to create a
>    whole new script, altperl/dump_schema.pl rather than making
>    subscribe_set.pl more complex.  subscribe_set.pl could always
>    _call_ dump_schema.pl, but having it separate permits it to be used
>    for things other than just establishing subscriptions.

My only objection to this is that I don't want to have a huge number of 
single-task scripts, because it makes it harder to find the one(s) you want. 
I'd like to start grouping them by "this is what I want to do" (e.g. get a 
set subscribed onto a destination) rather than "these are the steps I need 
to do it" (e.g. create the set, copy the schema, subscribe the set).

That's a different RFC, though, and I'm still formulating that proposal. 
But it's relevant in explaining why I wouldn't just create another script. 
I'm not opposed to putting it in slon-tools.pm instead of subscribe_set.pl, 
though.

> 3.  I presume that the script goes to the origin to get the schema,
>    right?

Yep.

--
Steve Simms <steve at deefs.net>
http://www.deefs.net