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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: advance local xmin more aggressively
Следующее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: Optimization rules for semi and anti joins