Greg Smith <gsm...@gregsmith.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers