Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-01-04 09:38:42 -0500, Stephen Frost wrote:
> Andres,
>
> * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > On 2017-01-03 10:37:08 -0500, Stephen Frost wrote:
> > > * Vladimir Rusinov (vrusinov(at)google(dot)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?
>
> I outlined exactly that in the part you didn't quote.

Sure, but my point was that you and several others essentially argue for
breaking things gratuitously. And I think that's bad. That you can live
with backward compatibility doesn't change that point.

> > > 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.
>
> I agree that we have been breaking monitoring tools on the regular for a
> while as we continue to add capabilities and improve things, which is
> part of the reason that I don't see this particular break as a very big
> deal- serious monitoring tools are going to need to be updated anyway.

I have no problem with breaking things when necessary. I do have a
problem when we do so willy-nilly when providing backward-compatibility
would have been easy enough. E.g. Nearly all recent pg_stat_activity
changes would have been doable just as well without breakage.

> I don't see that changing any time soon either- we are woefully far
> behind in this area compared to other databases and we should be trying
> to encourage people to continue improving these areas, not making things
> unnecessairly difficult by requiring backwards compatibility hacks.

By breaking stuff on a regular basis we're also showing that we're
behind. Compatibility also is a big topic. We also force users to stay
behind longer, and to upgrade less frequently.

Andres