On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > As regards cost/benefit analysis, this is a low importance feature, > but then that is why I proposed a low effort fix that is flexible to > the needs of users affected.
Is there any feature that is more loathed and more narrowly used than rules? What about hash indexes? It is suspicious if we cannot identify even one feature that is more pain than gain to target for removal. In any case, I think it's important to keep an open mind to planning deprecations, and I say that as someone who is directly and hugely negatively impacted by deprecated features -- however, it is important to do them slowly. I think the choice of rules was a pretty credible one to bring up for consideration. The most sensible conservative deprecation plan I can think of sense is to only remove the feature when no release under project support claims to support -- without deprecation warning -- that feature. So, all in all, a four year deprecation window. I think this makes sense for features that are not in urgent need of deprecation but chip away at time spent serving defects or making them work with more desirable features. Because of this long pipeline in ideal cases, there is some benefit to starting in advance before everyone gets fed up and wants it removed Real Soon. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
