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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
