The fundamental disagreement here is over what qualifies as a "wishlist" item, aka a feature or added functionality. And what qualifies as a must-fix bug.
Priorities are context sensitive. If this were early in the cycle then working on bigger impact features like conflict resolution code might be more important because it's important to get them into the code base where other people can see if it solves their problems and the behaviour can be tweaked. Fixing rare but outright broken things might not be high priority because while they have to be done by release nobody is blocking on on the solution before then. On the other hand near release we stop trying to incorporate new features and focus on basic bug features. The new features don't become any less important to the users, it's just that they'll make it into the next release. There will always be more features that can help users and we'll always think of cool new things to knock off the rough edges off what we have now and get it out so we can go back to the playground for the next release. You said "I think we should extend the time available to make sure we have a sensible set of features for 9.0." Perhaps part of the problem is that I couldn't understand what your patch did from the description you posted and can't evaluate whether it's fixing a problem that makes the current feature set incoherent. Can you explain what it does in more detail so we can understand why it's necessary for a sensible set of features? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers