> > 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 no problem with that ... but I see no logical relationship 
between
the frequency of schema modification and whether stored procedures
are to be used or not.

>   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.

Define 'stable' ... there is a difference between 'pretty stable' and 
'fixed'.

> If the schema is not stable, I'd suggest that the data in those
> tables can't be that valuable, so replication may not be what you
> need of the data.

Adding new tables/columns does not in any way imply that data in
existing tables/columns is not valuable.

What I'm concerned with is usability (user friendliness).  When a client
using my software needs to tag some records with extra information,
I don't what them to have to phone me up and ask me to modify things
when they can do it themselves.  They don't want to learn to use psql
and slonik, and I don't want to give them the ability to accidentally 
break things ...
so I need to provide a safe, user friendly interface.

Now, whether the user friendly interface is implemented by wrapping
calls to stored procedures over jdbc or by generating parameterised
slonik scripts, the issues are much the same ...
How can errors be detected and handled, and do the schema modifying
operations get reliably synchronised with data storage operations?

Anyone know?