On Thu, Oct 11, 2012 at 11:55 PM, Simon Riggs <simon@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
