On 11/01/2014 09:00 PM, Michael Paquier wrote: > 1) It is untested and actually there is no direct use for it in core. > 2) Pushing code that we know as dead is no good, that's a feature more > or less defined as maybe-useful-but-we-are-not-sure-yet-what-to-do-with-it. > 3) If you're going to re-use this API in BDR, which is a fork of > Postgres.
I would like to emphasise that BDR is not really a fork at all, no more than any big topic branch would be a fork. BDR is two major parts: - A collection of patches to core (commit timestamps/extradata, sequence AM, replication identifiers, logical decoding, DDL deparse, event triggers, etc). These are being progressively submitted to core. maintained as multiple feature branches plus a merged version; and - An extension that uses core features and, where necessary, the additions to core to implement bi-directional logical replication. Because of the time scales involved in getting things into core it's been necessary to *temporarily* get the 9.4-based feature branch into wider use so that it can be used to run the BDR extension, but if we can get the required features into core that need will go away. Event triggers and logical decoding were already merged in 9.4. If we can get things like commit timestamps, commit extradata / logical replication identifiers, the sequence access method, etc merged in 9.5 then it should be possible to do away with the need for the patches to core entirely and run BDR on top of stock 9.5. I'd be delighted if that were possible, as doing away with the patched 9.4 would get rid of a great deal of work and frustration on my part. Note that the BDR extension its self is PostgreSQL-licensed. Externally maintained extensions have been bought in-core before. It's a lot of code though, and I can't imagine that being a quick process. > You'd better complete this API in BDR by yourself and not > bother core with that. This argument would've prevented the inclusion of logical decoding, which is rapidly becoming the headline feature for 9.4, or at least shortly behind jsonb. Slony is being adapted to use it, multiple people are working on auditing systems based on it, and AFAIK EDB's xDB is being adapted to take advantage of it too. As development gets more complex and people attempt bigger features, the One Big Patch that adds a feature and an in-core user of the feature is not going to be a viable approach all the time. In my view it's already well past that, and some recent patches (like RLS) really should've been split up into patch series. If we want to avoid unreviewable monster-patches it will, IMO, be necessary to have progressive, iterative enhancement. That may sometimes mean that there's code in core that's only used by future yet-to-be-merged patches and/or by extensions. Of course its desirable to have an in-tree user of the code wherever possible/practical - but sometimes it may *not* be possible or practical. It seems to me like the benefits of committing work in smaller, more reviewable chunks outweigh the benefits of merging multiple related but separate changes just so everything can have an immediate in-tree user. That's not to say that extradata must remain glued to commit timestamps. It might make more sense as a separate patch with an API to allow extensions to manipulate it directly, plus a dummy extension showing how it works, like we do with various hooks and with APIs like FDWs. However, just like the various hooks that we have, it *does* make sense to have something in-core that has no "real world" in-core users. -- Craig Ringer 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
