[snip, but noted]
> My suggestion is to look at the SPI code, the sync code, and the
> original concept/design doc all together, to get a clear idea of how
> it's supposed to work.  If you do that, you can probably see where
> the hinky bits are, and then you can explore further the extent to
> which it's worth doing.

OK, so my conclusion is that it worths the effort to look into it. I'll
do that and come back with my conclusions (which are not necessarily the
best, but guided by our company interest in the end).

> I suspect that, from a community point of view, the design of such a
> beast would need a few additional things to be a candidate for
> inclusion with Slony.  Off the top of my head, I'd say that at least
> a proposal for how to go the other way (from Postgres to Oracle)
> would be very nice, 

Well, given that slony is messing with all the constraint/foreign
key/index stuff in very postgres DB specific way on the slave so
obviously that even me who does not know too much about slony internals
am aware of it, I'm pretty sure the slave part is the harder one to
implement... I mean more work. Not to mention we don't need that right
now... so for me a step by step thing with enabling master first would
be better.

> the option to turn it off at build time (or, more
> likely, an --enable-oracle-compat or something), 

This is a must, oracle would for sure need additional libraries to
compile the thing.

> and some outline of
> what limitations the additional support would impose (I bet there are
> datatypes that _will_ have problems, and we'd need to catch those
> somehow).  

I'm more worried about the changes needed to abstract out the oracle
code would need too much change in the existing code so it would become
an additional maintenance burden for the existing developers. OTOH, it
could have unexpected logical cleanup effects ;-)

> The goal of all of that is to avoid having pieces of the
> code that are very "bare metal".  Slony has the number of safeguards
> it does precisely because we concluded previous systems were too easy
> to use as devices for self-inflicted injury; and we still get things
> that people do to themselves where the docs say DON'T DO THIS ON PAIN
> OF FOOT SHOT.

Point taken, and I guess the cleanup effects I mentioned could mean such
a modularization for example to allow a server and a client capability
to be provided separately, so slony can work in the presence of just one
or the other too. Then I could simply say in the first oracle
implementation that the slave capability is not present.

Cheers,
Csaba.