On 11/10/14, 4:58 PM, Andres Freund wrote:
> But the main reason all this is interesting isn't so much CREATE
> itself. But that it can be (and Alvaro has mostly done it!) for ALTER as
> well. And there it imo becomes really interesting. Because you can quite
> easily check whether the affected relation is being replicated you can
> just emit the DDL when that's the case. And that makes DDL in a
> logically replicated setup*much* easier.
+1. Adding columns is a PITA, you have to manually ensure you do it on all slaves first.
Drop is somewhat worse, because you have to do it on the master first, opposite of the (more usual) case of adding a
column.
RENAME is a complete disaster.
Handing scripts to your replication system to execute isn't a very good alternative either; it assumes that you
actuallyhave a script (bad assumption with ORMs), and that you have a reasonable way to get that script to wherever you
runyour replication system.
I will also weigh in that there are a LOT of cases that binary replication doesn't cover. I find it interesting that
priorto creating built in replication, the community stance was "We won't build that because there's too many different
usecases", but now some folks are saying that everyone should just use streaming rep and be done with it. :P
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
