The main reason for these limitations is that Slony-I
collects updates using triggers, and neither schema changes nor large
object operations are captured by triggers

There is a capability for Slony-I to propagate notably DDL changes
if you submit them as scripts via the slonikSLONIK EXECUTE SCRIPT operation. That is not handled
"automatically;" you, as a database administrator, will
have to construct an SQL DDL script and submit it, via SLONIK EXECUTE SCRIPT.

If you have these sorts of requirements, it may be worth
exploring the use of PostgreSQL 8.0+ PITR (Point In
Time Recovery), where WAL logs are replicated to
remote nodes.