> This discussion reveals that it's time to start making some > discussions about what can be accomplished for 9.1 and what must be > postponed to 9.2. The big ones I think we should postpone are:
First off, I think that this is a little premature. As others have pointed out, the unusual schedule this development cycle indicates that we ought to give patch authors *some* leeway, otherwise we're penalizing patch authors who worked hard on 9.0 Beta compared to people who ignored 9.0. I don't think that extends to another commitfest, but I would be OK with extending this commitfest by two weeks to ensure that every feature gets a full review. > - Range Types. This is a large patch which was submitted for the > first time to the last CommitFest of the cycle, and the first version > that had no open TODO items was posted yesterday, three-quarters of > the way through that last CommitFest. Some good review has been done. > While more is probably needed, I think we should feel good about > what's been accomplished and mark this one Returned with Feedback. Aside from it needing more feedback, and being personally disappointed, I think this is inevitable. Jeff seems OK with it too. > - ALTER EXTENSION UPGRADE. This is another large patch which was > submitted for the first time to the last CommitFest of the cycle. The I thought we'd *already* decided to postpone this, due to the spec still being muddy. No? > - FOR KEY LOCK tables. This patch, unfortunately, has not gotten a > lot of review. But it's a major, potentially destabilizing change I think this needs to get a full review before we make any decisions on it. > - SQL/MED. This patch unfortunately kind of stalled for a long time. > However, I believe that Heikki is now working actively on the core > patch, so I'm hopeful for some activity here soon. I'll point out that SQL/MED with File_FDW would be a majorly useful feature, even if other FDWs didn't yet work. So a partial commit is also a possibility. > - Writeable CTEs. Tom has promised to look at this, but doesn't seem > to be in a hurry. I think it would be tremendously unfair to the author to punt this feature unless there's fundamental flaws in it. Its development started back in 9.0, and it's never really gotten enough review/attention. --Josh Berkus -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers