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 actually have a script (bad assumption with ORMs), and that you have a reasonable way to get that script to wherever you run your 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 prior to creating built in replication, the community stance was "We won't build that because there's too many different use cases", 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
