Re: Add CREATE support to event triggers
От | Jim Nasby |
---|---|
Тема | Re: Add CREATE support to event triggers |
Дата | |
Msg-id | 54616E22.9030708@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Add CREATE support to event triggers (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Add CREATE support to event triggers
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: