Re: A deprecation policy
От | Tom Lane |
---|---|
Тема | Re: A deprecation policy |
Дата | |
Msg-id | 10620.1234370593@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: A deprecation policy ("D'Arcy J.M. Cain" <darcy@druid.net>) |
Список | pgsql-hackers |
"D'Arcy J.M. Cain" <darcy@druid.net> writes: > Peter Eisentraut <peter_e@gmx.net> wrote: >> 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. > As long as they can remove the item giving the warning right away. Well, they could only remove the item if it was *already* the case that it didn't do anything. In general, I think Peter neglected to address the question of whether "deprecated" objects/functions/etc still have their original functionality, and where along the path the replacement functionality starts to exist. It's certainly a bad idea to be throwing warnings about something that people still have to use. regards, tom lane
В списке pgsql-hackers по дате отправления: