On 2014-11-08 12:07:41 -0500, Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On 2014-11-08 11:52:43 -0500, Tom Lane wrote: > >> Adding a similar > >> level of burden to support a feature with a narrow use-case seems like > >> a nonstarter from here. > > > I don't understand this statement. In my experience the lack of a usable > > replication solution that allows temporary tables and major version > > differences is one of the most, if not *the* most, frequent criticisms > > of postgres I hear. How is this a narrow use case? > > [ shrug... ] I don't personally give a damn about logical replication, > especially not logical replication implemented in this fashion.
"In this fashion" meaning ddl replication via event triggers? If you have an actual suggestion how to do it better I'm all ears. So far nobody has come up with anything. > Or in short: AFAICS you're not building the next WAL-shipping replication > solution, you're building the next Slony, and Slony never has and never > will be more than a niche use-case. A good number of the sites out there use either londiste or slony. Not because they like it, but because there's no other alternative. I'd love to simply say that we can make WAL based replication work across versions, platforms and subsets of relations in PG clusters. Since that seems quite unrealistic people have to go different ways. > Putting half of it into core wouldn't fix that, it would just put a > lot more maintenance burden on core developers. Imo stuff that can't be done sanely outside core needs to be put into core if it's actually desired by many users. And working DDL replication for logical replication solutions surely is. > Core developers are entitled to push back on such proposals. I'm not saying "core developers" (whover that is) aren't allowed to do so. But just because they think something is (too) invasive doesn't make it a niche application. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
