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@gregsmith.com http://www.gregsmith.com Baltimore, MD