From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A deprecation policy |
Date: | 2009-02-11 16:43:13 |
Message-ID: | 10620.1234370593@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"D'Arcy J.M. Cain" <darcy(at)druid(dot)net> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2009-02-11 16:44:33 | Re: Optimization rules for semi and anti joins |
Previous Message | Jeff Davis | 2009-02-11 16:40:08 | Re: advance local xmin more aggressively |