On Sun, Jul 16, 2017 at 10:27 PM, Greg Stark <stark@mit.edu> wrote:
> On 15 July 2017 at 23:00, Tom Lane <tgl@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