Greg Smith wrote:
> I've submitted two changes to this CommitFest that are enhancing
> features in this "core extensions" set. Right now I have multiple
> customers who are desperate for both of those features. With
> extensions, I can give them changes that solve their immediate crisis
> right now, almost a full year before they could possibly appear in a
> proper release of PostgreSQL. And then I can push those back toward
> community PostgreSQL, with any luck landing in the next major version.
> Immediate gratification for the person funding development, and peer
> reviewed code that goes through a long beta and release cycle. That's
> the vision I have for a PostgreSQL that is simultaneously stable and
> agile. The easiest way to get there it is to lead by example--by having
> extensions that provide necessary, visible components to core, while
> still being obviously separate components. That's the best approach for
> proving this development model works and is suitable for everyone.
I think a question is how often people are waiting for features that
actually can be addressed in a contrib/plugin way. My gut feeling is
that most missing features have to be added to the server core (e.g.
index-only scans) and are not possible to add in a contrib/plugin way.
I am not saying this would not help, but I am saying that this is going
to address only a small part of the goal of getting features to users
quicker.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
