Re: A deprecation policy

Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> 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.

[ rolls eyes ... ]

$ psql regression
psql (8.4devel)
Type "help" for help.

regression=# set sort_mem = 100;
SET
regression=# show sort_mem;
work_mem
----------
100kB
(1 row)

regression=#

It's not like we go out of our way to break applications; if there's an
easy compatibility workaround, we generally provide it. In particular
I think that Peter's proposal is mainly thinking about cases where it's
practical to provide a "deprecated" feature and its replacement behavior
concurrently --- at worst being able to switch between one and the other
via a GUC or some such. The hard part, and the question that's missing
from this discussion, is exactly what we'll do when backwards
compatibility is impractical (for whatever size of "impractical" suits
you; there is *always* going to be a point where it's not worth it).
Peter's proposal appears to require that changes in that category have
to be agreed to and announced two years before the change is actually
made. Frankly I don't believe that's going to happen. The original
proposer will have lost interest, or the original patch will have
bit-rotted beyond usefulness, or even more likely somebody will want
the patch bad enough to convince us not to wait two years. (Witness
the annual arguments about how feature FOO should go into the current
release because its developer isn't willing to wait *one* year.)

regards, tom lane