Peter,
3. In release N+2, if there were no protests in response to step 2, deprecated features are removed.
The main issue I can see with this is that most production sites only upgrade once every 2-3 years. So they'd tend to miss warnings entirely.
I would also extend this system to removed configuration settings, e.g., max_fsm_*. We should make these deprecated for one release, so (1) configuration files can be upgraded without manual work (relevant to in-place upgrade), and (2) users are alerted that their carefully crafted configuration might need a review.
I think the combination of a config file generator (in development now) with a config file checker (something we could use anyway) would take care of any config file issues.
I did actually give some thought to a config file converter, but the number of options which are new, changed names, changed names and changed meanings, changed options, or went away makes it an n^2 issue and not really worth solving. Just tell the people to run the new version of the config file generator.
The other thing we could use would be clearer documentation on this sort of thing. That is, a single page in the docs which talks about what was depreciated in specific versions. We kinda do this in the release notes, but the notices often aren't that clear and are mixed in with a lot of other stuff. Probably we should just clear this up in the release notes.
--Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
