| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Something for the TODO list: deprecating abstime and friends |
| Date: | 2017-07-17 15:27:16 |
| Message-ID: | CA+TgmoZESwm2LN=SZLOJBPpxrD_FDrcPgDK1q-7mH6PGs6hOew@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jul 16, 2017 at 1:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2017-07-17 15:29:33 | Re: AdvanceXLInsertBuffer vs. WAL segment compressibility |
| Previous Message | Michael Paquier | 2017-07-17 15:16:19 | Re: Unportable use of select for timeouts in PostgresNode.pm |