Peter Eisentraut 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
Hi,
Peter Eisentraut wrote:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence.
+1 (I'm reading this as a very general proposal also targeting C APIs,
not only GUCs).
Comments?
With the proposed policy we'd have to recommend
On Wed, Feb 11, 2009 at 2:47 AM, Peter Eisentraut pete...@gmx.net wrote:
We often discuss changing user-visible behavior of various kinds and are
usually clueless on the question of someone might rely on this or how
many people are still using this etc. Still, it is clearly often useful to
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut pete...@gmx.net wrote:
1. In release N, an interface is declared obsolete, which means that
[...]
2. In release N+1, obsolete interfaces are declared deprecated, which
I like the idea but aren't these two terms reversed? In fact, isn't
D'Arcy J.M. Cain da...@druid.net wrote:
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut pete...@gmx.net wrote:
1. In release N, an interface is declared obsolete, which means
[...]
2. In release N+1, obsolete interfaces are declared deprecated,
I like the idea but aren't these two
D'Arcy J.M. Cain da...@druid.net writes:
Peter Eisentraut pete...@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
Peter Eisentraut pete...@gmx.net writes:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence. My proposed policy goes like
this:
I've been thinking about this for a couple of hours, and I keep coming
back to the conclusion that if
Peter,
3. In release N+2, if there were no protests in response to step 2,
deprecated features are removed.
The main issue I can see with this is that most production sites only
upgrade once every 2-3 years. So they'd tend to miss warnings entirely.
I would also extend this system to
On Wed, 11 Feb 2009, Josh Berkus wrote:
I did actually give some thought to a config file converter, but the number
of options which are new, changed names, changed names and changed meanings,
changed options, or went away makes it an n^2 issue and not really worth
solving.
My next big push
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 ... ]
$
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I have been thinking, with a semi-formal deprecation policy, we could
make these decisions with more confidence. My proposed policy goes like
this:
I've been thinking about this for a couple of hours, and I keep coming
back to
We often discuss changing user-visible behavior of various kinds and are
usually clueless on the question of someone might rely on this or how
many people are still using this etc. Still, it is clearly often
useful to revise interfaces from time to time.
I have been thinking, with a
12 matches
Mail list logo
