On 9/7/2004 1:02 PM, Andrew Sullivan wrote:

> On Tue, Sep 07, 2004 at 05:42:23PM +0100, Richard Frith-Macdonald wrote:
>> The documentation focusses on using slonik rather than calling the 
>> stored procedures directly ...
>> does this imply that use of the stored procedures is discouraged or 
>> that the api is unstable?
> 
> The former.  Slony is designed on the assumption that schema changes
> to the database are a rare occurrence.  I have heard Jan argue that
> systems that change their own schemas are guilty of being
> self-modifying code.  Whether that charge is just, the notion is
> still that the schema needs to be pretty stable.

The API is as stable as one can hope for a 1.0 release, it's use isn't 
discouraged at all. But I have today added an argument to an API 
function, and funny enough it is the one executing DDL scripts.

However, as long as slonik is the only caller of them, I don't bother 
with using function overloading to emulate the old behaviour. As soon as 
other projects like pgadmin or phppgadmin are using them, this will be 
done where possible.

That said, the real problem in Slony with schema changes is that all 
affected tables must be in one and the same replication set, all tables 
in the set have to get locked exclusively, the replication triggers 
removed, original application triggers restored, the ddl script 
executed, application triggers disabled again and the replication 
triggers put back into place. From all this, the "locked exclusively" is 
the really nasty part. But there is no way how slony otherwise could 
guarantee that there is a point inside of the replication stream where 
it can clearly define "these transactions committed before the alter 
table, and those after". So it would have a problem to execute that 
script in between exactly the same transactions.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #