Tom Lane wrote:
> Peter Eisentraut 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 co
Greg Smith 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
ps
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
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 remov
Peter Eisentraut 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 we actually e
"D'Arcy J.M. Cain" writes:
> 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),
>>> "D'Arcy J.M. Cain" wrote:
> On Wed, 11 Feb 2009 09:47:25 +0200
> Peter Eisentraut 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 terms reversed
On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut 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
"obsolete" y
On Wed, Feb 11, 2009 at 2:47 AM, Peter Eisentraut 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
> revise int
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 us
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 caref
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 semi-
12 matches
Mail list logo
