Re: A deprecation policy

On Wed, 11 Feb 2009, Josh Berkus wrote:

> 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.

My next big push for pgtune is to backport the pg_settings additions I
need to 8.3/8.2/8.1 and assemble a proper settings database for all those
versions. Once I finish that, it will be trivial to flag and remove all
the parameters that aren't even there anymore, which at least reduces the
size of n quite a bit.

For the specific case that's been mentioned here, does it even matter if
somebody has some old settings for max_fsm_* in their 8.4 postgresql.conf
file? Ditto for other deprecated parameters like bgwriter_all_percent.
I think that if you ignore everything that just dropped altogether, and
just worry about settings whose meaning has changed, the number you'd have
left to worry about is much smaller. Unfortunately, those are the hard
ones to identify, too.

Anyway, I read Peter's suggestion as aiming more at SQL features and API
changes, rather than configuration file ones. In trivial cases like
sort_mem->work_mem, adding some backward compatibility concessions might
make sense. Saddling GUC changes with any restrctions beyond what happens
to be easy seems pretty impractical.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD