Re: [HACKERS] Something for the TODO list: deprecating abstime and friends - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Date
Msg-id CA+TgmoZESwm2LN=SZLOJBPpxrD_FDrcPgDK1q-7mH6PGs6hOew@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Something for the TODO list: deprecating abstime and friends  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jul 16, 2017 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Or in other words, I don't want to go from
> "might disappear" in vN to gone in vN+1 with no intermediate state.

I see no problem with that.  First, we remove things all the time with
no deprecation warning at all when we judge that they are dead enough,
or just unsalvageable.  Second, if we have said that something might
disappear and then it disappears, anyone who is unhappy about that is
being unreasonable.

In other words, I don't want to have a project policy that we will not
only put a deprecation notice on everything we remove, but it will
always be worded in a certain way.  If you're trying to streamline the
process of deprecating features, that's going in the exact wrong
direction.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Unportable use of select for timeouts in PostgresNode.pm
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility