Greg Smith wrote:
> Tom Lane wrote:
>
> > Taking out features after they've been in a release is very hard, even if we realize they're badly
> > designed.
> >
>
> It doesn't have to be; that's the problem the "release often" part takes
> care of. If a release has only been out a year, and a new one comes out
> saying "oh, that thing we released for the first time in the last
> version, it didn't work as well as we'd hoped in the field; you should
> try to avoid that and use this new implementation that works better
> instead once you can upgrade", that's not only not hard, it's exactly
> what people using a X.0 release expect to happen.
I think this is the crux of the issue. Tom and I are saying that
historically we have shipped only complete features, or as complete as
reasonable, and have removed items during beta that we found didn't meet
this criteria, in an attempt to reduce the amount of feature set churn
in Postgres. A database is complex, so modifying the API between major
releases is something we only do when we find a significant benefit.
In this case, if we keep max_standby_delay as non-boolean, we know it
will have to be redesigned in 9.1, and it is unclear to me what
additional knowledge we will gain by shipping it in 9.0, except to have
to tell people that it doesn't work well or requires complex
work-arounds, and that doesn't thrill any of us. (I already suggested
that statement_timeout might supply a reasonable and predictable
workaround for non-boolean usage of max_standby_delay.)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
