> The problem is there is no way to catch the lo_import(). And if you could, I'm 
> not sure you could preserve the oid of the LO between nodes. All of this puts 
> you down the path of replicating LO's at the application level I'd think.

Well, I wouldn't do it that way. What would work for me:

 - remember BLOB fields in some slony table (they must be OID type);
 - the store trigger for that table would special case the blob field,
and when it's changed, it would replicate instead of the OID the BLOB
content;
 - the replica will also special case the BLOB field and store the BLOB
content and set the BLOB field to the local OID of the stored BLOB (this
means the OIDs would differ between the master and the replica, which
makes the BLOB field not suitable for participating in the slony key,
but I guess that wouldn't be needed anyway);

 - when deleting a row, the BLOB can be deleted (we never store the same
BLOB OID in multiple tables), and the replica can delete the
corresponding BLOB with the replica's OID;

The restrictions of this model would be:

 - can't replicate BLOB changes;
 - don't put the same BLOB's OID in multiple tables, so that the BLOB
deletion works;
 - can't use the BLOB field in the slony unique key;

I guess it's easier to design the application respecting these
restrictions than write an application level slony add-on to replicate
BLOBs...

Is any of this looking reasonable ?

Thanks,
Csaba.