On Mon, Jul 17, 2017 at 11:37 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> 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).
Yeah, but historically it never works out. A relatively famous
example is contrib/xml2, whose documentation says:
==
From PostgreSQL 8.3 on, there is XML-related functionality based on
the SQL/XML standard in the core server. That functionality covers XML
syntax checking and XPath queries, which is what this module does, and
more, but the API is not at all compatible. It is planned that this
module will be removed in a future version of PostgreSQL in favor of
the newer standard API, so you are encouraged to try converting your
applications. If you find that some of the functionality of this
module is not available in an adequate form with the newer API, please
explain your issue to <pgsql-hackers@postgresql.org> so that the
deficiency can be addressed.
==
But until 3163baa6d2d12c28f45fec60ab313537ea9a43a4 (February 24,
2013), it said that it would be removed in PostgreSQL 8.4 (July 1,
2009), a promise that could not be fulfilled without the use of a
serviceable time machine. I proposed removing contrib/xml2 sometime
during the 8.4 or 9.0 cycle, IIRC, and got told "no". While the
updated deprecation notice is less-obviously wrong, saying that
removal is "planned" is a pretty generous assessment. It's unclear
that we've made any progress in addressing whatever the problems were
that caused the previous attempt at removal to get shot down, so it
might still be wrong: maybe xml2 is going to stick around until the
heat death of the universe.
Now, I agree that a date type which cannot represent dates after 2038
is of marginal and decreasing utility, and therefore the chances that
it will be removed are good. Probably most other people will agree as
well. But we could easily overlook the need to deliver on a promise
to remove it in a specific version, and the possibility that someone
will argue for keeping it as a matter of historical interest cannot be
ruled out. In a community where anything at all can be relitigated at
the drop of a hat, making promises about what will happen in the
future is mostly wishful thinking.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company