Re: CATUPDATE confusion?

All,

Sure, if we never deprecate anything then tool authors would never need
> to change their existing code. I don't think that's actually a viable
> solution though; the reason we're discussing the removal of these
> particular views is that they aren't really being maintained and, when
> they are, they're making work for us. That's certainly a trade-off to
> consider, of course, but in this case I'm coming down on the side of
> dropping support and our own maintenance costs associated with these
> views in favor of asking the tooling community to complete the migration
> to the new views which have been around for the past 10 years.
>

Perhaps this is naive or has been attempted in the past without success,
but would it be possible to maintain a list of deprecated features? I
noticed the following wiki page, (though it hasn't been updated recently)
that I think could be used for this purpose.

https://wiki.postgresql.org/wiki/Deprecated_Features

Using this page as a model, having an "official deprecation list" that does
the following might be very useful:

* Lists feature that is deprecated.
* Reason it was deprecated.
* What to use instead, perhaps with example.
* Version the feature will be removed.

Or perhaps such a list could be included as part of the official
documentation? In either case, if it is well known that such a list is
available/exists then tool developers, etc. should have adequate time,
opportunity and information to make the appropriate changes to their
products with a "minimal" impact.

Thoughts?

-Adam

--
Adam Brightwell - adam(dot)brightwell(at)crunchydatasolutions(dot)com
Database Engineer - www.crunchydatasolutions.com