On Mon, Jul 17, 2017 at 11:37 AM, Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers