It's very hard, merging schemas manually is painful and leads to errors. I'm writing this from experience..

Such tool is on my list since long ago, but unfortunately there is only 24 hours in the day :)

Some years ago, I wrote a tool to merge databases. There were a few differences in schema that it handled through configuration, but the tool was mostly about changing primary and foreign keys as it transferred the data so the merges wouldn't clash.

What's your use-case on "merging schemas"? Does it not merge data? Is it like you have a database with a table with columns "foo", and "bar", and then another database with a table with columns "bar", and "baz" and you want one of the database to end up with columns "foo", "bar", and "baz" without moving any of the actual data?

I'm using all sort of building blocks, I recall functions, views, custom types, triggers, publications on per-table basis. In most cases I don't allow for my schemas to divert, but there had been situations like developing next generation of the system where for reasons out of my memory I had to wait till job was done and then merge schemas. Probably this could have been avoided but in the same time I was not there when decisions was made :)

I see--it's not so much the diff but applying that diff.

Oh yes, writing patch is one thing, write migration is the next level.