Hi,
On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> * Vladimir Rusinov (vrusinov@google.com) wrote:
> > I think I +1 on this.
> > I've did a github search on these function names and there is a lot of code
> > that use them. E.g. there is 8.5k hits for pg_last_xlog_location
> > <https://github.com/search?q=pg_last_xlog_replay_location&type=Code&utf8=%E2%9C%93>;
> > a lot of them a forks and copy-pastes, but still, that's quite a lot. Let's
> > keep the aliases around for couple of versions after which hopefully a lot
> > of the code will be updated.
>
> And there's 12k hits for pg_xlog.
> If we do that, we'll just end up with exactly the same question about
> removing them and the same amount of code breakage in a few years. I
> don't see how that is really helping anyone.
Meh^2. The cost of having pg_xlog was that people lost their
data. Hence their was motivation of changing things. The cost of having
some function aliases is, what, a pg_proc line? If we end up carrying
them forever, so what?
> If we really feel that this is the only thing between 9.6 and 10 that'll
> cause problems for some serious amount of code and we don't expect to
> change the function APIs anytime in the near future then perhaps we
> could keep aliases, *document* them, and treat them as full functions
> just like the regular ones.
I think we've been far to cavalier lately about unnecessarily breaking
admin and monitoring tools. There's been pg_stat_activity backward
incompat changes in most of the last releases. It's a *PAIN* to develop
monitoring / admin tools that work with a number of releases. It's fine
to cause that pain if there's some considerable benefit (e.g. not
triggering data loss seems like a case for that, as imo is unifying
configuration), but I don't see how that justifying breaking things
gratuitously. Just renaming well known functions for a minor bit of
cleanliness seems not to survive a cost/benefit analysis.
Greetings,
Andres Freund