> - At subscription time, the providers data is copied over en masse using
> COPY.  That may not work entirely well with Oracle ;-). 
> 
> Presumably one could replace the COPY statements with suitable sets of
> INSERTs, albeit at some not-inconsiderable performance costs.  That
> would be a not-too-enormous SMOP (Small Matter of Programming).

I presume it would be possible to write some oracle function which
produces an output compatible with the postgres COPY output, and use
that function instead of COPY. I'm not that familiar with oracle, but we
have here others who are and would help :-)

> - Ongoing updates are submitted as ordinary database requests: INSERT,
> DELETE, and UPDATE statements.  The contents are all Plain Old Text, so
> for sorts of column types that correspond well between Oracle and
> PostgreSQL, this shouldn't present any problems. 

This is all good then.

> Column types that don't correspond will be a problem, of course.  It
> would presumably be possible to set up column wrapper functions to do
> translations for things that *nearly* correspond.  That would be a
> somewhat tricky but, again, not enormous, SMOP.

Well, non-corresponding field types would be a problem for postgres to
postgres too...
For our DBs the only non-corresponding types are boolean, which in
Oracle we simulate as NUMBER(1) and use 0/1 for false/true. However
postgres already can properly cast 0/1 to false/true, it has just to be
made an implicit cast to work (it's not implicit by default).
I'm not aware of any other types which are standard enough that you
would want to replicate them between oracle and postgres... the very
fact that you want to replicate between stock oracle and stock postgres
implies somewhat that you need to design the schema with compatibility
in mind.
The missing pieces for us would be BLOBS, but those are anyway not
replicable between postgres instances either.

> The tricky part is getting transaction visibility right.  That's the
> thing about Slony-I that's "really really clever," and I'm not sure how
> it would translate to running a data provider on Oracle.  Look at Jan's
> early papers for more details on that; they're in the slony1-engine/doc/
> area.

Well it must be possible to solve, there are replication solutions for
oracle too :-)
Exactly how, that's a matter of more study...

In any case, this thread got a lot more attention already than I was
expecting.

Thanks,
Csaba.