On Sun, Jul 16, 2017 at 10:27 PM, Greg Stark <st...@mit.edu> wrote: > On 15 July 2017 at 23:00, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> While it's too late in the v10 cycle to do anything very meaningful >> about this now, I am tempted to strengthen the deprecation notice's >> wording from "might disappear" to "will disappear". > > "Will certainly disappear at some unspecified date" is a lot less > convincing than "will disappear in 2021 in Postgres 14". The specific > year and version number is irrelevant > but picking and naming a specific one makes it a lot easier to follow > through come that date.
Exactly, having an exact deprecation policy would be nice. Of course this depends on the feature we are talking about. pg_dump for example supports servers older than what community still supports. But in most cases, like in core data types, it would be rather safe to say that it gets deprecated once all the versions supported by community share the same state (remember for example 17d436d2 that was kept around for a rather long time, or the handling of opaque function types for triggers and PLs still present for 15 years). Coming back to this thread... Removing abstime and reltime sounds like the good answer to conclude this thread once the deprecation period expires. -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers