Greetings,
* Vik Fearing (vik@postgresfriends.org) wrote:
> On 5/19/20 4:03 AM, Tom Lane wrote:
> > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> >> What are the thoughts about then marking the postfix operator deprecated
> >> and eventually removing it?
> >
> > If we do this it'd require a plan. We'd have to also warn about the
> > feature deprecation in (at least) the CREATE OPERATOR man page, and
> > we'd have to decide how many release cycles the deprecation notices
> > need to stand for.
>
> I have never come across any custom postfix operators in the wild, and
> I've never even seen ! used in practice.
>
> So I would suggest a very short deprecation period. Deprecate now in
> 13, let 14 go by, and rip it all out for 15. That should give us enough
> time to extend the deprecation period if we need to, or go back on it
> entirely (like I seem to remember we did with VACUUM FREEZE).
>
> > If that's the intention, though, it'd be good to get those deprecation
> > notices published in v13 not v14.
>
> +1
I agree with putting notices into v13 saying they're deprecated, but
then actually removing them in v14. For that matter, I'd vote that we
generally accept a system whereby when we commit something that removes
a feature in the next major version, we put out some kind of notice that
it's been deprecated and won't be in v14. We don't want to run the risk
of saying XYZ has been deprecated and then it staying around for a few
years, nor trying to say "it'll be removed in v14" before we actually
know that it's been committed for v14.
In other words, wait to deprecate until the commit has happened for v14
(and maybe wait a couple days in case someone wasn't watching and argues
to revert, but not longer than any normal commit), and then go back and
mark it as "deprecated and removed in v14" for all back-branches. Users
will continue to have 5 years (by upgrading to v13, or whatever the last
release was before their favorite feature was removed, if they really
need to) to update their systems to deal with the change.
We do not do ourselves nor our users a real service by carrying forward
deprecated code/interfaces/views/etc, across major versions; instead
they tend to live on in infamy, with some users actually updating and
some not, ever, and then complaining when we suggest actually removing
it (we have lots of good examples of that too) and then we have to have
the debate again about removing it and, in some cases, we end up
un-deprecating it, which is confusing for users and a bit ridiculous.
Let's not do that.
Thanks,
Stephen
