On Tue, Mar 22, 2016 at 1:18 PM, Magnus Hagander <magnus@hagander.net> wrote:
> Most of that was committed *after* our discussion. It's definitely a very
> solid release now. (and I agree that was a somewhat weird feature credit in
> 9.4,but hey, we also got most of our json publicity for the one in 9.2, not
> the really useful one in 9.4. Our track record with these things isn't
> really the best..).
Yes, it's been a busy couple of weeks. But I'd also point out, if you
look at the last few releases, that the background worker major
feature credit wasn't incredibly exceptional. For example, 9.4 also
gave a major feature credit to "Allow materialized views to be
refreshed without blocking concurrent reads", but I think few people
would argue that materialized views as they exist in PG today are a
first-class feature - for that, we need *incremental* refresh. We got
"Reduce lock strength for some ALTER TABLE commands", but only
rarely-used commands that aren't really the major problem with ALTER
TABLE. The really big thing in 9.4, technologically speaking, was
"Add support for logical decoding of WAL data, to allow database
changes to be streamed out in a customizable format". But that was
another C API. A bloody good one, to be sure, but a C API all the
same. In contrast, the big stuff we have in 9.6 is all stuff you can
really use.
> Is it enough for 10.0? I'm still doubtful. If more of the stuff that's in
> the queue now gets committed, there's definitely a chance I'll change my
> mind. But we shouldn't decide on version numbers based on what might happen,
> only on what actually happens.
Sure, let's see what else we get. Are you working on committing any
of that stuff in the queue? What that's still in the queue are you
particularly excited about?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company