Andres, all, * Andres Freund (and...@anarazel.de) wrote: > On 2017-09-25 19:32:29 +0200, Petr Jelinek wrote: > > On 25/09/17 19:26, Tom Lane wrote: > > > Alvaro Hernandez <a...@ongres.com> writes: > > >> In my opinion, logical decoding plugins that don't come with core > > >> are close to worthless (don't get me wrong): > > > > > >> - They very unlikely will be installed in managed environments (an area > > >> growing significantly). > > >> - As anything that is not in core, raises concerns by users. > > >> - Distribution and testing are non-trivial: many OS/archs combinations. > > > > > > The problem with this type of argument is that it leads directly to the > > > conclusion that every feature users want must be in core. We can't > > > accept that conclusion, because we simply do not have the manpower or > > > infrastructure to maintain a kitchen-sink, Oracle-sized code base. > > > I think we're already more or less at the limit of the feature set we can > > > deal with :-(. The entire point of the output-plugin design was to allow > > > useful replication stuff to be done outside of core; we need to make use > > > of that. (If that means we need better docs, then yeah, we'd better get > > > that part done.) > > I obvoiusly agree that not every possible output plugin should be put > into core. A number of them have significant external dependencies > and/or are specialized for a certain environment. > > However I don't think that should mean that there's no possible output > plugin that could/should be integrated into core. And I think Petr's > right here: > > > There is already about 3 million output plugins out there so I think we > > did reasonable job there. The fact that vast majority of that are > > various json ones gives reasonable hint that we should have that one in > > core though.
I tend to agree with Andres & Petr here as well. No, we certainly don't want to add features that aren't going to be used much to core or which stretch the resources we have beyond what we're able to handle, but having a good, solid, output plugin that works well and can be built upon should be included into core. PG is often deployed in complex ecosystems where we need to work with other systems and this is an important part of that. Also, to some extent, I'm hopeful that being both open to new features, when they make sense, and providing more ways for other systems to work with PG, will lead to more contributions and hopefully regular contributors who can help us maintain the code base as it continues to grow. Thanks! Stephen
signature.asc
Description: Digital signature
